From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 02:38:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECE093E0 for ; Sun, 5 Oct 2014 02:38:57 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7AC391DA for ; Sun, 5 Oct 2014 02:38:57 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s952cWUL096680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Oct 2014 11:38:44 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s952cUKR051561; Sun, 5 Oct 2014 11:38:32 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 05 Oct 2014 11:38:14 +0900 (JST) Message-Id: <20141005.113814.1118248190693149915.hrs@allbsd.org> To: hariprasad@chelsio.com Subject: Re: Detaching the slave from the lagg interface which has vlan on top of it, hits an panic From: Hiroki Sato In-Reply-To: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> References: <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Oct__5_11_38_14_2014_248)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sun, 05 Oct 2014 11:38:48 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 02:38:58 -0000 ----Security_Multipart(Sun_Oct__5_11_38_14_2014_248)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hariprasad S wrote in <26E3F92EC670BD429DB5CB319D773C137A8878@nice.asicdesigners.com>: ha> HI, ha> ha> Detaching the slave from the lagg interface which has vlan on top of it, hits an panic. ha> Kernel used: FreeBSD HEAD r272051 ha> ha> Is anyone aware of this issue? Could you try r272547 or later? -- Hiroki ----Security_Multipart(Sun_Oct__5_11_38_14_2014_248)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlQwrxYACgkQTyzT2CeTzy2ThACgk5rLKcWPnlCrIYhlrADc5OGl sg4AoJ62ZbN9kS1kXLMMIhLu08jyTA7Z =zzpK -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Oct__5_11_38_14_2014_248)---- From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 03:46:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BB3D28F for ; Sun, 5 Oct 2014 03:46:12 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16BC9A6B for ; Sun, 5 Oct 2014 03:46:11 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cc10so4257015wib.2 for ; Sat, 04 Oct 2014 20:46:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=mwqqujrDR2zUehi4CMew72XTN0i4qK0fx/O8afGGQXk=; b=kLkOyfv/vJ24C3FP1u5k8vqrDuwLphN1J/OEM9+tKaLFO5C3nR2KiIPBHi8Ujrpfg6 Nll8Msc8BDTXJWwop0l6STbDpXfNlz9naVcLlETvs5ZJiL2FRIshQExDIF28EbbPqybD x/dqk+nhQUPd0NpR8wdGFaAdj+ao+Fld+9JCbrh7yidFmdbn+1vmzFPzFq8YNqIYy8Hy fURc40/i7suBwNino5Ub8y3tgpm7FgyqUXA6DE31ezZ3xWfw9X5HJn4lWLlPyRe6OuSI DP4/2Rli+u4FHXX5TcG+C9pJqB2CDcSpg+OWGOlaVi2iUoWvLvJrS3HTS5Mx28GjkAfE 3fYA== X-Gm-Message-State: ALoCoQlcC2uDxD4idFKA+kPlsN5da2bLBOaV6fUsKrD/02curFLnE689uviuyWGpZE1ojiLvlBqz MIME-Version: 1.0 X-Received: by 10.180.20.139 with SMTP id n11mr9854010wie.22.1412480764314; Sat, 04 Oct 2014 20:46:04 -0700 (PDT) Received: by 10.27.94.16 with HTTP; Sat, 4 Oct 2014 20:46:04 -0700 (PDT) Date: Sat, 4 Oct 2014 23:46:04 -0400 Message-ID: Subject: remote host accepts loose source routed IP packets From: el kalin To: freebsd-net@freebsd.org, freebsd-users@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 03:46:12 -0000 hi all=E2=80=A6 i'm setting up a freebsd 10 on aws (amazon) to be as secure as possible=E2= =80=A6 i used openvas to scan it and pretty much everything is fine except this: "The remote host accepts loose source routed IP packets. The feature was designed for testing purpose. An attacker may use it to circumvent poorly designed IP filtering and exploit another flaw. However, it is not dangerous by itself. Solution: drop source routed packets on this host or on other ingress routers or firewalls." there is no "other ingress routers or firewalls." except the AWS "security group" which only has open ports 80, 443 and 22 and allICMP for pinging... on the instance itself i have this already set up... in /etc/sysctl.conf i have: net.inet.ip.accept_sourceroute=3D0 in /etc/derfaults/rc.conf i got: accept_sourceroute=3D"NO" # sysctl -a | grep accept_sourceroute net.inet.ip.accept_sourceroute: 0 i also have a pf enabled locally pretty much with the same ports as the security group. can i use pf to drop those packets? how do i drop the source routed packets? without this i can't pass a pci scan=E2=80=A6 thanks... From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 06:04:55 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71A594E3 for ; Sun, 5 Oct 2014 06:04:55 +0000 (UTC) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0229A7F8 for ; Sun, 5 Oct 2014 06:04:54 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cc10so4350927wib.4 for ; Sat, 04 Oct 2014 23:04:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zbhVE02iGvwpmZebUL4n1W9Er8j2rmRqv6l59mNa5Fk=; b=jBJfLOS/peA72HuP0IalgldHPPlIBJ/vwLc50W0JCVjR9IWaHFIXHwKOgoWteU6LGq 4D7jlfSJ4N0n3lxvgzZzY5rNOAMndEld9b5DMfMTdTiTo7o9HM/iSz4trJOdn2KFtAth rK4ozeOtDlcBmXAE05BRT/GsKV387cmAlxXJidIETLcokC3fGVTIEE/z8w0GQpfm9yGP 7mQZhZcb4w0Zp62QkRj8ukKUB7YckBVHFXh1Z2Dv0Qa3uguFNFsAVsudAVf2qs7JDMya TIUOFVFPYTNfJJFCqW7lskD/pyHIOoT7ruNUjleisSRr63572vX7M4jL3Lmye5UMvYty PLcA== X-Gm-Message-State: ALoCoQlAccVNRBF9Ld6qyq8iWcYHizpaxiqwg+Ix4v/LtRRI9ARBj1HeFv32rLSuRqoLMSNS2UkP MIME-Version: 1.0 X-Received: by 10.180.20.139 with SMTP id n11mr10483471wie.22.1412489092887; Sat, 04 Oct 2014 23:04:52 -0700 (PDT) Received: by 10.27.94.16 with HTTP; Sat, 4 Oct 2014 23:04:52 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 02:04:52 -0400 Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: el kalin To: freebsd-net , freebsd-users@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 06:04:55 -0000 hi again=E2=80=A6 i have disabled the icmp pings=E2=80=A6 same result... currently: /etc/pf.conf: tcp_in =3D "{ www, https }" udp =3D "{ domain, ntp, snmp }" ping =3D "echoreq" set skip on lo scrub in antispoof for xn0 inet block in all pass out all keep state pass out inet proto udp from any to any port 33433 >< 33626 keep state pass proto udp to any port $dup ### pass inet proto icmp all icmp-type $ping keep state pass in inet proto tcp to any port $tcp_in flags S/SAF synproxy state pass proto tcp to any port ssh # sysctl -a | grep sourceroute net.inet.ip.sourceroute: 0 net.inet.ip.accept_sourceroute: 0 in /etc/defaults/rc.conf: forward_sourceroute=3D"NO" accept_sourceroute=3D"NO" what am i missing? this is pretty important=E2=80=A6. thanks=E2=80=A6.. On Sat, Oct 4, 2014 at 11:46 PM, el kalin wrote: > > hi all=E2=80=A6 > > i'm setting up a freebsd 10 on aws (amazon) to be as secure as possible= =E2=80=A6 > i used openvas to scan it and pretty much everything is fine except this: > > "The remote host accepts loose source routed IP packets. > The feature was designed for testing purpose. > An attacker may use it to circumvent poorly designed IP filtering > and exploit another flaw. However, it is not dangerous by itself. > Solution: > drop source routed packets on this host or on other ingress > routers or firewalls." > > there is no "other ingress routers or firewalls." except the AWS "securit= y > group" which only has open ports 80, 443 and 22 and allICMP for pinging..= . > > on the instance itself i have this already set up... > > in /etc/sysctl.conf i have: > > net.inet.ip.accept_sourceroute=3D0 > > in /etc/derfaults/rc.conf i got: > > accept_sourceroute=3D"NO" > > > # sysctl -a | grep accept_sourceroute > net.inet.ip.accept_sourceroute: 0 > > i also have a pf enabled locally pretty much with the same ports as the > security group. can i use pf to drop those packets? > > how do i drop the source routed packets? > without this i can't pass a pci scan=E2=80=A6 > > thanks... > > > From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 06:33:00 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20BD4901; Sun, 5 Oct 2014 06:33:00 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtpout002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EAF7FA25; Sun, 5 Oct 2014 06:32:59 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCY001IPKUF9940@st11p02mm-asmtp002.mac.com>; Sun, 05 Oct 2014 06:32:41 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-05_02:2014-10-03,2014-10-05,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410050075 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1988\)) Subject: Re: [PATCH] Only lock send buffer in sopoll() if needed From: Rui Paulo In-reply-to: <201409301400.09999.jhb@freebsd.org> Date: Sat, 04 Oct 2014 23:32:38 -0700 Content-transfer-encoding: quoted-printable Message-id: <5442AFCD-14D1-4CCE-B86E-140C534E2C95@me.com> References: <201409301400.09999.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1988) Cc: Robert Watson , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 06:33:00 -0000 On Sep 30, 2014, at 11:00, John Baldwin wrote: >=20 > Right now sopoll() always locks both socket buffers. The receive = socket=20 > buffer lock is always needed, but the send socket buffer lock is only = needed=20 > while polling for writing (there is a potential test of = SBS_CANTSENDMORE=20 > without the lock, but I think this might be ok). What do folks think? Does this really help us much? Are you worried about sending data when = another thread is polling? The patch looks ok, but I'm not sure about the handling of POLLHUP. I = suppose that's okay since if that flag is set, the socket is = disconnected. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 07:09:04 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C680F9E; Sun, 5 Oct 2014 07:09:04 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 49113CB8; Sun, 5 Oct 2014 07:09:04 +0000 (UTC) Received: from [10.0.1.12] (79-64-249-234.host.pobb.as13285.net [79.64.249.234]) by cyrus.watson.org (Postfix) with ESMTPSA id BCFED46B2A; Sun, 5 Oct 2014 03:08:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH] Only lock send buffer in sopoll() if needed From: "Robert N. M. Watson" In-Reply-To: <201409301400.09999.jhb@freebsd.org> Date: Sun, 5 Oct 2014 08:08:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9DED9207-89B7-47C3-B823-047A5FDFC511@FreeBSD.org> References: <201409301400.09999.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 07:09:04 -0000 I'm not convinced that the race with SBS_CANTSENDMORE is OK, even though = I really want to write that it is. The risk here is that we miss an = asynchronous disconnect event, and that the thread then blocks even = though an event is pending, which is a nasty turn of events. We might = want to dig about a bit and see whether this case 'matters' -- e.g., = that there are important cases where a test for writability might need = to catch SBS_CANTRCVMORE but SBS_CANTSENDMORE is not simultaneously set. Could you say a bit more about the performance benefits of this change = -- is it substantial? If so, we might need to add a new socket-buffer = flag along the lines of SB[RS]_DISCONNECTED that is 'broadcast' to both = socket buffers on certain events. Doing so might require rejiggering = elsewhere by causing additional locks to need to be held, possibly out = of order. Another thing that's worth pondering -- and it is a lot of work -- is = finally sorting out the conflation of SOCK_LOCK() and = SOCKBUF_LOCK(&so_rcv). We have a number of races in the socket state = machine stemming from this conflation (due to lockless reads along the = lines of the one you are proposing, only against so_state and friends). = This is a non-trivial change, and it's not 100% clear to me how to make = it, so would require quite a bit of analysis. It might have the effect = of needing three non-trivial adjustments: (1) instantiating two new = locks per socket, one sleepable, one a mutex; (2) rejiggering a set of = 'global' socket properties out from under the receive lock, such as (but = definitely not limited to) so_state; (3) doing some socket-layer vs. = protocol-layer rejiggering so that protocol state machine is the = 'primary' with event notifications to the socket layer to update its = state, as opposed to the current world order where some state = transitions are triggered by one layer, and some by the other. Although = not pretty, you can see an example of a resolution of a socket-protocol = race in the current behaviour of solisten, which used to drive the state = machine from the socket layer, which conflicted with protocol-layer = checks; now, the protocol uses the socket layer as a library to test = (and later set) properties. I don't think the issue you are looking at requires starting to dig into = that can of worms, but it is a long-standing problem in socket locking / = protocol-layer interaction that does need to get resolved in order to = make the behaviour of conditions like the one you are looking at 'more = natural'. Robert On 30 Sep 2014, at 19:00, John Baldwin wrote: > Right now sopoll() always locks both socket buffers. The receive = socket=20 > buffer lock is always needed, but the send socket buffer lock is only = needed=20 > while polling for writing (there is a potential test of = SBS_CANTSENDMORE=20 > without the lock, but I think this might be ok). What do folks think? >=20 > Index: uipc_socket.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- uipc_socket.c (revision 272305) > +++ uipc_socket.c (working copy) > @@ -3003,7 +3003,12 @@ sopoll_generic(struct socket *so, int events, = stru > { > int revents =3D 0; >=20 > - SOCKBUF_LOCK(&so->so_snd); > + if (events & (POLLOUT | POLLWRNORM)) > + SOCKBUF_LOCK(&so->so_snd); > + /* > + * The so_rcv lock doubles as SOCK_LOCK so it it is needed for > + * all requests. > + */ > SOCKBUF_LOCK(&so->so_rcv); > if (events & (POLLIN | POLLRDNORM)) > if (soreadabledata(so)) > @@ -3038,7 +3043,8 @@ sopoll_generic(struct socket *so, int events, = stru > } >=20 > SOCKBUF_UNLOCK(&so->so_rcv); > - SOCKBUF_UNLOCK(&so->so_snd); > + if (events & (POLLOUT | POLLWRNORM)) > + SOCKBUF_UNLOCK(&so->so_snd); > return (revents); > } >=20 > --=20 > John Baldwin From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 08:22:40 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59D9593; Sun, 5 Oct 2014 08:22:40 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 1288C381; Sun, 5 Oct 2014 08:22:40 +0000 (UTC) Received: from [10.0.1.12] (79-64-249-234.host.pobb.as13285.net [79.64.249.234]) by cyrus.watson.org (Postfix) with ESMTPSA id DADC846B0C; Sun, 5 Oct 2014 04:22:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [PATCH] Only lock send buffer in sopoll() if needed From: "Robert N. M. Watson" In-Reply-To: <201409301400.09999.jhb@freebsd.org> Date: Sun, 5 Oct 2014 08:08:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9DED9207-89B7-47C3-B823-047A5FDFC511@FreeBSD.org> References: <201409301400.09999.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1878.6) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 08:22:40 -0000 I'm not convinced that the race with SBS_CANTSENDMORE is OK, even though = I really want to write that it is. The risk here is that we miss an = asynchronous disconnect event, and that the thread then blocks even = though an event is pending, which is a nasty turn of events. We might = want to dig about a bit and see whether this case 'matters' -- e.g., = that there are important cases where a test for writability might need = to catch SBS_CANTRCVMORE but SBS_CANTSENDMORE is not simultaneously set. Could you say a bit more about the performance benefits of this change = -- is it substantial? If so, we might need to add a new socket-buffer = flag along the lines of SB[RS]_DISCONNECTED that is 'broadcast' to both = socket buffers on certain events. Doing so might require rejiggering = elsewhere by causing additional locks to need to be held, possibly out = of order. Another thing that's worth pondering -- and it is a lot of work -- is = finally sorting out the conflation of SOCK_LOCK() and = SOCKBUF_LOCK(&so_rcv). We have a number of races in the socket state = machine stemming from this conflation (due to lockless reads along the = lines of the one you are proposing, only against so_state and friends). = This is a non-trivial change, and it's not 100% clear to me how to make = it, so would require quite a bit of analysis. It might have the effect = of needing three non-trivial adjustments: (1) instantiating two new = locks per socket, one sleepable, one a mutex; (2) rejiggering a set of = 'global' socket properties out from under the receive lock, such as (but = definitely not limited to) so_state; (3) doing some socket-layer vs. = protocol-layer rejiggering so that protocol state machine is the = 'primary' with event notifications to the socket layer to update its = state, as opposed to the current world order where some state = transitions are triggered by one layer, and some by the other. Although = not pretty, you can see an example of a resolution of a socket-protocol = race in the current behaviour of solisten, which used to drive the state = machine from the socket layer, which conflicted with protocol-layer = checks; now, the protocol uses the socket layer as a library to test = (and later set) properties. I don't think the issue you are looking at requires starting to dig into = that can of worms, but it is a long-standing problem in socket locking / = protocol-layer interaction that does need to get resolved in order to = make the behaviour of conditions like the one you are looking at 'more = natural'. Robert On 30 Sep 2014, at 19:00, John Baldwin wrote: > Right now sopoll() always locks both socket buffers. The receive = socket=20 > buffer lock is always needed, but the send socket buffer lock is only = needed=20 > while polling for writing (there is a potential test of = SBS_CANTSENDMORE=20 > without the lock, but I think this might be ok). What do folks think? >=20 > Index: uipc_socket.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- uipc_socket.c (revision 272305) > +++ uipc_socket.c (working copy) > @@ -3003,7 +3003,12 @@ sopoll_generic(struct socket *so, int events, = stru > { > int revents =3D 0; >=20 > - SOCKBUF_LOCK(&so->so_snd); > + if (events & (POLLOUT | POLLWRNORM)) > + SOCKBUF_LOCK(&so->so_snd); > + /* > + * The so_rcv lock doubles as SOCK_LOCK so it it is needed for > + * all requests. > + */ > SOCKBUF_LOCK(&so->so_rcv); > if (events & (POLLIN | POLLRDNORM)) > if (soreadabledata(so)) > @@ -3038,7 +3043,8 @@ sopoll_generic(struct socket *so, int events, = stru > } >=20 > SOCKBUF_UNLOCK(&so->so_rcv); > - SOCKBUF_UNLOCK(&so->so_snd); > + if (events & (POLLOUT | POLLWRNORM)) > + SOCKBUF_UNLOCK(&so->so_snd); > return (revents); > } >=20 > --=20 > John Baldwin From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 10:15:44 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2BF8C19 for ; Sun, 5 Oct 2014 10:15:44 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C56E1A0 for ; Sun, 5 Oct 2014 10:15:44 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XaerU-000Fdv-2B; Sun, 05 Oct 2014 10:00:04 +0400 Message-ID: <54311A05.8050200@FreeBSD.org> Date: Sun, 05 Oct 2014 14:14:29 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Marcelo Gondim , freebsd-net@freebsd.org Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> <542FFD95.5050200@bsdinfo.com.br> In-Reply-To: <542FFD95.5050200@bsdinfo.com.br> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 10:15:44 -0000 On 04.10.2014 18:00, Marcelo Gondim wrote: > Excellent work! :) > I really enjoyed the news. This new ipfwcome with FreeBSD 10.1 release? Unfortunately, no. The plan is to commit it to HEAD and merge to 9/ and 10/ after 1 month. > > Cheers, > Gondim > > On 04/10/2014 09:35, Alexander V. Chernikov wrote: >> Hi, >> >> I'm going to merge projects/ipfw branch to HEAD in the middle of next >> week. >> >> What has changed: >> >> Main user-visible changes are related to tables: >> >> * Tables are now identified by names, not numbers. There can be up to >> 65k tables with up to 63-byte long names. >> * Tables are now set-aware (default off), so you can switch/move them >> atomically with rules. >> * More functionality is supported (swap, lock, limits, user-level >> lookup, batched add/del) by generic table code. >> * New table types are added (flow) so you can match multiple packet >> fields at once. >> * Ability to add different type of lookup algorithms for particular >> table type has been added. >> * New table algorithms are added (cidr:hash, iface:array, >> number:array and flow:hash) to make certain types of lookup more >> effective. >> * Table value are now capable of holding multiple data fields for >> different tablearg users >> >> Some examples (see ipfw(8) manual page for the description): >> >> 0:02 [2] zfscurr0# ipfw table fl2 create type >> flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib >> 0:02 [2] zfscurr0# ipfw table fl2 info >> +++ table(fl2), set(0) +++ >> kindex: 0, type: flow:src-ip,proto,dst-port >> valtype: number, references: 0 >> algorithm: flow:hash >> items: 0, size: 280 >> 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 >> 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 >> 0:02 [2] zfscurr0# ipfw table fl2 list >> +++ table(fl2), set(0) +++ >> 2a02:6b8::333,6,443 45000 >> 10.0.0.92,6,80 22000 >> 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 >> 80 flow 'table(fl2)' >> >> ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" >> ipfw table mi_test add 10.0.0.8/30 >> ipfw table mi_test add 2a02:6b8:b010::1/64 25 >> >> # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 >> added: 1.1.1.1/32 1111 >> added: 2.2.2.2/32 2222 >> # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 >> exists: 2.2.2.2/32 2200 >> added: 4.4.4.4/32 4444 >> ipfw: Adding record failed: record already exists >> ^^^^^ Returns error but keeps inserted items >> # ipfw table si list >> +++ table(si), set(0) +++ >> 1.1.1.1/32 1111 >> 2.2.2.2/32 2222 >> 4.4.4.4/32 4444 >> # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 >> 5.5.5.5/32 5555 >> added(reverted): 3.3.3.3/32 3333 >> exists: 4.4.4.4/32 4400 >> ignored: 5.5.5.5/32 5555 >> ipfw: Adding record failed: record already exists >> ^^^^^ Returns error and reverts added records >> >> Performance changes: >> * Main ipfw lock was converted to rmlock >> * Rule counters were separated from rule itself and made per-cpu. >> * Radix table entries fits into 128 bytes >> * struct ip_fw is now more compact so more rules will fit into 64 bytes >> * interface tables uses array of existing ifindexes for faster match >> >> ABI changes: >> All functionality supported by old ipfw(8) remains functional. Old & >> new binaries can work together with the following restrictions: >> * Tables named other than ^\d+$ are shown as table(65535) in ruleset >> in old binaries >> * I'm a bit unsure about "lookup src-port|dst-port N" case, something >> may be broken here. Anyway, this can be fixed for MFC >> >> Internal changes:. >> Changing table ids to numbers resulted in format modification for >> most sockopt codes. >> Old sopt format was compact, but very hard to extend (no versioning, >> inability to add more opcodes), so >> * All relevant opcodes were converted to TLV-based versioned >> IP_FW3-based codes. >> * The remaining opcodes were also converted to be able to eliminate >> all older opcodes at once >> * All IP_FW3 handlers uses special API instead of calling sooptcopy* >> directly to ease adding another communication methods >> * struct ip_fw is now different for kernel and userland >> * tablearg value has been changed to 0 to ease future extensions >> * table "values" are now indexes in special value array which holds >> extended data for given index >> * Batched add/delete has been added to tables code >> * Most changes has been done to permit batched rule addition. >> * interface tracking API has been added (started on demand) to permit >> effective interface tables operations >> * O(1) skipto cache, currently turned off by default at compile-time >> (eats 512K). >> >> * Several steps has been made towards making libipfw: >> * most of new functions were separated into "parse/prepare/show and >> actuall-do-stuff" pieces (already merged). >> * there are separate functions for parsing text string into "struct >> ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). >> * Probably some more less significant/forgotten features > > _______________________________________________ > 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 Sun Oct 5 12:34:16 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4CF69FC; Sun, 5 Oct 2014 12:34:16 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D615129; Sun, 5 Oct 2014 12:34:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=jAcTV5aO3UurYVUkMwF3k61Xnhst4RsFxb7XySD7YdU=; b=dU0v3UTJVX/+wNCrIQGRi2uNaKsOewliTe5HZSFylCL/N6EhWUU8JgowBnX9Z17k9mbMq2dsv8qIF3trS/FEkwYrvoJs8f7EahW5uFGWXCicvIyJhCkORm3WjfWadNmAHyJFDUSVYqLDcEQ58nm3C53pQwCX2cc7M9ClqAp6T9s=; Received: from [182.1.193.13] (port=14242 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xal0w-004KbJ-4P; Sun, 05 Oct 2014 06:34:14 -0600 Date: Sun, 5 Oct 2014 20:34:01 +0800 From: Erich Dollansky To: Glen Barber Subject: Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails Message-ID: <20141005203401.440afc31@X220.alogt.com> In-Reply-To: <20141005013247.GH1171@hub.FreeBSD.org> References: <20141005013247.GH1171@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: FreeBSD Release Engineering Team , freebsd-jail@freebsd.org, freebsd-stable@FreeBSD.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 12:34:16 -0000 Hi, On Sat, 4 Oct 2014 21:32:47 -0400 Glen Barber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > The first RC build of the 10.1-RELEASE release cycle is now available I installed this shortly after your e-mail came. The result was the same as with BETA3. If you remember, I have had the problem that the network inside jails stopped working after I installed BETA3. The upgrade to RC1 did not change anything. I took now the time to investigate a bit. The result is simple. All works as expected until lagg becomes enabled. If I remember right, BETA1 was my last working version. I have an em and an iwn interface in the machine. I can use both of them without any problems. As I can reproduce this problem 100%, it might be a good idea if I help you to find the source of the problem. My problem would be: how. If somebody could tell me where to start looking for the error, we might find it soon. Erich From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 14:43:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A23620F; Sun, 5 Oct 2014 14:43:08 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDF1AEDD; Sun, 5 Oct 2014 14:43:07 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id fp1so1960611pdb.7 for ; Sun, 05 Oct 2014 07:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nC8aHCvKehL8qJgc9izQpfo4r/Bj1ZWBZChFo/RQfBw=; b=LdyaSPczZQBlHhxNzs+ekAnv1H11GtLVW3M4lLwqgrpIUctfHHkMjNoQFejXIKqVAz 3cTAECW8k/FWU2cD1o+uNksZE47gVYDHaQvtiTbM710yFLxudpxAs3mHVnk2MmT6jvcF klDyH/5sBo493HJc4eFkIRi0QR8ozj6AyID9TTLBYJH9maSoD05SlGlP9NzKB4Xcrsvh Xrci8BBGis7WMJK9/R+Ue9wNgnR4QCffH8BnLMHqOLAYXTvXm2puBoyQZeo+dgCeT9Yk SK4kP/sdIeuEjWzcB78n+fH21pDJKLqaeO7JNSFTMffc/nOUoMsOgPPT4VZ+ClUrTp+l jkAQ== X-Received: by 10.70.36.237 with SMTP id t13mr1609964pdj.134.1412520187414; Sun, 05 Oct 2014 07:43:07 -0700 (PDT) Received: from [192.168.1.100] ([175.156.202.12]) by mx.google.com with ESMTPSA id g6sm8873653pdj.0.2014.10.05.07.43.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Oct 2014 07:43:06 -0700 (PDT) Message-ID: <543158F7.2070505@gmail.com> Date: Sun, 05 Oct 2014 22:43:03 +0800 From: bycn82 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org Subject: Re: HEADS UP: Merging projects/ipfw to HEAD References: <542FE9A7.9090208@FreeBSD.org> In-Reply-To: <542FE9A7.9090208@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 14:43:08 -0000 On 10/4/14 20:35, Alexander V. Chernikov wrote: > Hi, > > I'm going to merge projects/ipfw branch to HEAD in the middle of next > week. > > What has changed: > > Main user-visible changes are related to tables: > > * Tables are now identified by names, not numbers. There can be up to > 65k tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them > atomically with rules. > * More functionality is supported (swap, lock, limits, user-level > lookup, batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet > fields at once. > * Ability to add different type of lookup algorithms for particular > table type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array > and flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for > different tablearg users > > Some examples (see ipfw(8) manual page for the description): > > 0:02 [2] zfscurr0# ipfw table fl2 create type > flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 > 80 flow 'table(fl2)' > > ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 > > # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 > added: 1.1.1.1/32 1111 > added: 2.2.2.2/32 2222 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 4444 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 1111 > 2.2.2.2/32 2222 > 4.4.4.4/32 4444 > # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 > 5.5.5.5/32 5555 > added(reverted): 3.3.3.3/32 3333 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 5555 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error and reverts added records > > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 bytes > * interface tables uses array of existing ifindexes for faster match > > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & > new binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset > in old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something > may be broken here. Anyway, this can be fixed for MFC > > Internal changes:. > Changing table ids to numbers resulted in format modification for most > sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, > inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned > IP_FW3-based codes. > * The remaining opcodes were also converted to be able to eliminate > all older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* > directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds > extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit > effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time > (eats 512K). > > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and > actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct > ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features > > _______________________________________________ > 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" > Hi, Good job, Waiting for your code :) Regards, Bycn82 From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 15:33:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D986C3A for ; Sun, 5 Oct 2014 15:33:46 +0000 (UTC) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D56B403 for ; Sun, 5 Oct 2014 15:33:45 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id n3so2529507wiv.3 for ; Sun, 05 Oct 2014 08:33:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5VH1TwCpjoWepC+slrtfZ4mDCND3756XOc/wgBYc+2Y=; b=ToaE3qMh++6pOUHPmCC55JfApe/76cZOPbiWm6q/nqIpWQEKheKij9+MelJTPd4HAx Mtx1Le5Oc+xoU5ItMyFn2Rf+4UQZicNo7c6dy/57EoG285QVPQuy1MPl/lCMBgN9qlR1 ikBwobji1PAs+6T9SmNjB5Q8lGQ8NmiG19S3L7fdnUnO7uiKt+M3Ao12z/4KiMH7Sjhr 29JE6JNg+dVf0901MXAXyE1ibO6Cgdqop7BTyrTyCC6ghLX3aq4sA+uejjdJ/ybTiXiB 3cR/f1XaTA3o5t5PJd/365gI+1AQ3i/hABVoQbXlsYOlc269a7ijMQDiCF9OH/ziWoLN aVyg== X-Gm-Message-State: ALoCoQkPYkGayIshPBZlASzooGEtB5TzFM01h7UpIFKcWN+3Nktz4pzVdL/KwY5b37XPAX8swloH MIME-Version: 1.0 X-Received: by 10.194.246.2 with SMTP id xs2mr22338672wjc.33.1412523218315; Sun, 05 Oct 2014 08:33:38 -0700 (PDT) Received: by 10.27.94.16 with HTTP; Sun, 5 Oct 2014 08:33:38 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 11:33:38 -0400 Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: el kalin To: freebsd-net , freebsd-users@freebsd.org, freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 15:33:46 -0000 should is submit this as a bug? On Sun, Oct 5, 2014 at 2:04 AM, el kalin wrote: > hi again=E2=80=A6 i have disabled the icmp pings=E2=80=A6 same result..= . > > currently: > > /etc/pf.conf: > > tcp_in =3D "{ www, https }" > udp =3D "{ domain, ntp, snmp }" > ping =3D "echoreq" > > set skip on lo > scrub in > antispoof for xn0 inet > block in all > pass out all keep state > pass out inet proto udp from any to any port 33433 >< 33626 keep state > pass proto udp to any port $dup > ### pass inet proto icmp all icmp-type $ping keep state > pass in inet proto tcp to any port $tcp_in flags S/SAF synproxy state > pass proto tcp to any port ssh > > > # sysctl -a | grep sourceroute > net.inet.ip.sourceroute: 0 > net.inet.ip.accept_sourceroute: 0 > > in /etc/defaults/rc.conf: > > forward_sourceroute=3D"NO" > accept_sourceroute=3D"NO" > > > what am i missing? this is pretty important=E2=80=A6. > > thanks=E2=80=A6.. > > > > On Sat, Oct 4, 2014 at 11:46 PM, el kalin wrote: > >> >> hi all=E2=80=A6 >> >> i'm setting up a freebsd 10 on aws (amazon) to be as secure as possible= =E2=80=A6 >> i used openvas to scan it and pretty much everything is fine except this= : >> >> "The remote host accepts loose source routed IP packets. >> The feature was designed for testing purpose. >> An attacker may use it to circumvent poorly designed IP filtering >> and exploit another flaw. However, it is not dangerous by itself. >> Solution: >> drop source routed packets on this host or on other ingress >> routers or firewalls." >> >> there is no "other ingress routers or firewalls." except the AWS >> "security group" which only has open ports 80, 443 and 22 and allICMP fo= r >> pinging... >> >> on the instance itself i have this already set up... >> >> in /etc/sysctl.conf i have: >> >> net.inet.ip.accept_sourceroute=3D0 >> >> in /etc/derfaults/rc.conf i got: >> >> accept_sourceroute=3D"NO" >> >> >> # sysctl -a | grep accept_sourceroute >> net.inet.ip.accept_sourceroute: 0 >> >> i also have a pf enabled locally pretty much with the same ports as the >> security group. can i use pf to drop those packets? >> >> how do i drop the source routed packets? >> without this i can't pass a pci scan=E2=80=A6 >> >> thanks... >> >> >> > From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 15:58:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 427F336E for ; Sun, 5 Oct 2014 15:58:11 +0000 (UTC) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 023FF857 for ; Sun, 5 Oct 2014 15:58:10 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id x3so3023764qcv.10 for ; Sun, 05 Oct 2014 08:58:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OhTgb16ZmqLQ5T0PKQWHC8gghfSEwilujIzu6lk+XQU=; b=i8KBHuOVP8iHr1tri/xQOT33wogyol+CcprEatoXM2im4yFmZD3wUas4aHyosbkC+M e649MuX4BAI0fT5TOqmOotA3dK5sonTHbHp39htl4qE/hdL7Tyuyw+07VONO3XXJpYE7 yYq/mryXMlf4qULAH5ytC0JD5ByprGNpHx1ycsEXvEouHYcH5E9UC9++PCRAmpBlCid5 OHrymkvdx1+LYANx5dSRhmdEJVXd7bKBeeGWod2JDgfWne7tGmzPZtJ2Z1k9R7rsND3h 2L2zZw1n3fikDknEXCRndMP4wfeK8LIBM/dq3fb0bwdqP5UWE0LiW6ik9U1tlehgNu1T 9TBw== X-Gm-Message-State: ALoCoQmqqfWJxgzDq7o5l5fa87unWqxTJkFw3cdSN0OoIqvCGl3RDv+pedNlou8kEJSx1gFqcUD5 MIME-Version: 1.0 X-Received: by 10.224.26.146 with SMTP id e18mr3217109qac.96.1412524683994; Sun, 05 Oct 2014 08:58:03 -0700 (PDT) Received: by 10.140.95.193 with HTTP; Sun, 5 Oct 2014 08:58:03 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 08:58:03 -0700 Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: Brandon Vincent To: el kalin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net , freebsd-users@freebsd.org, freebsd-security@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 15:58:11 -0000 On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: > should is submit this as a bug? Can you first try adding "set block-policy return" to pf.conf? OpenVAS might be assuming that a lack of response from your system to source routed packets is an acknowledgement that it is accepting them. Brandon Vincent From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 16:38:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FFB7B0A; Sun, 5 Oct 2014 16:38:50 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7082ABEE; Sun, 5 Oct 2014 16:38:49 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id z12so4812345wgg.1 for ; Sun, 05 Oct 2014 09:38:47 -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=FXt2vO22Acd9nfQmxJwlvWo7CLSREI/mZ1swBTNyGCo=; b=Bf4IIFWRxhpJTvAGdQA4aXw3diAAPbhTdyCqpJJ0xjcO0rr/8m3qvRcYj7XIOfkGh1 Ta0+WKZ+qGB9AhprIDiVO6HEtXiLyLLbp2uzM0hG9QWhhMc4m39jBBDagoOlH1yM8Fwf 8XkqypGk8TIkrb6cnn3lvhlnwefdgy5s2mlW7mc8oPecFAYZ/hKoAM93EC+ukj2wDj6v CgzFoomUlNL28+E69awjvPVwLQ7jbI1lE+ZtMLfMCaH5I5AA4mXC3HGlSeC0MmH5uu2s qL1ZoT9KG6hOeyvQ8+K2BTQ0czCbJkA4jOYXyh/hYFLoeq6Pmra7ofXnkbUBDcHbsSR3 op3w== MIME-Version: 1.0 X-Received: by 10.194.57.237 with SMTP id l13mr24066398wjq.102.1412527127747; Sun, 05 Oct 2014 09:38:47 -0700 (PDT) Received: by 10.27.46.14 with HTTP; Sun, 5 Oct 2014 09:38:47 -0700 (PDT) In-Reply-To: <20141005203401.440afc31@X220.alogt.com> References: <20141005013247.GH1171@hub.FreeBSD.org> <20141005203401.440afc31@X220.alogt.com> Date: Sun, 5 Oct 2014 11:38:47 -0500 Message-ID: Subject: Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails From: Scot Hetzel To: Erich Dollansky Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , freebsd-jail@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Stable , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 16:38:50 -0000 On Sun, Oct 5, 2014 at 7:34 AM, Erich Dollansky wrote: > Hi, > > On Sat, 4 Oct 2014 21:32:47 -0400 > Glen Barber wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> The first RC build of the 10.1-RELEASE release cycle is now available > > I installed this shortly after your e-mail came. The result was the > same as with BETA3. If you remember, I have had the problem that the > network inside jails stopped working after I installed BETA3. The > upgrade to RC1 did not change anything. > > I took now the time to investigate a bit. The result is simple. All > works as expected until lagg becomes enabled. > > If I remember right, BETA1 was my last working version. > > I have an em and an iwn interface in the machine. I can use both of them > without any problems. > > As I can reproduce this problem 100%, it might be a good idea if I help > you to find the source of the problem. My problem would be: how. > > If somebody could tell me where to start looking for the error, we > might find it soon. > You'll need to identify where in the src caused the issue for you. To do this, you will need to identify where it was working (BETA1?). You would then have to step thru the sources until you find the point where it breaks. The easiest way would be to take the svn revision that is half way between BETA1 and BETA3, compile and install it and see if it works. You keep halving the result until you identify the commit that broke it. Once the offending commit is identified, email the list. -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 17:17:10 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 563246D9 for ; Sun, 5 Oct 2014 17:17:10 +0000 (UTC) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE72CFBE for ; Sun, 5 Oct 2014 17:17:09 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id fb4so2660573wid.0 for ; Sun, 05 Oct 2014 10:17:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fG6YcLWAmkpBG9NQ+wYB3GHaoXppelKGl9XA9Zjxh0M=; b=XKrhJjWQItia4iPglGHXuxX4c7PZHtk+1fdDOAoJ59gWoIkxOK4J6FwSBd9KmwOkBz psf/AThr8aPvOrh0Vt5PU/8whp2u6YApdoMD5RRTX3ghjPrR0QripLoXe28h5+pbo6lh WZ5JO9uQacPbd5/kwrcgKqqxnr6cY+RFXxUMUPk9PFRPHgNgzkSBygMDqM4sZUUbYOj5 LezbVDWxWo/P3WRwWJ+OzGcDnfyMRM6LNcr3XZ2rDhDMDvALZpCHB9Jd9k9tWWvqpNDt Plnd06lJM5a2ZM4H28ZZvFaTiARXUzawo1I8+5zYuS9OHfk+ubkpZ/DV0afErhx/oO4L ky9A== X-Gm-Message-State: ALoCoQkc+2/x8EcoHLZJ3bn4wCF0zU75oEJwiSCdtlOAfa7f8+XcrCU+xY0S9l4rn5ALVVzFzqVW MIME-Version: 1.0 X-Received: by 10.180.184.225 with SMTP id ex1mr2696270wic.22.1412528972129; Sun, 05 Oct 2014 10:09:32 -0700 (PDT) Received: by 10.27.94.16 with HTTP; Sun, 5 Oct 2014 10:09:32 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 13:09:32 -0400 Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: el kalin To: Brandon Vincent Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net , freebsd-users@freebsd.org, freebsd-security@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 17:17:10 -0000 thanks brandon=E2=80=A6 but that didn't help=E2=80=A6. i still get the same result=E2=80=A6 i guess i'd report this as a bug=E2=80=A6 On Sun, Oct 5, 2014 at 11:58 AM, Brandon Vincent wrote: > On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: > > should is submit this as a bug? > > Can you first try adding "set block-policy return" to pf.conf? OpenVAS > might be assuming that a lack of response from your system to source > routed packets is an acknowledgement that it is accepting them. > > Brandon Vincent > From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 19:21:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F2677E0 for ; Sun, 5 Oct 2014 19:21:30 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1561E1F for ; Sun, 5 Oct 2014 19:21:29 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id cc10so2767532wib.17 for ; Sun, 05 Oct 2014 12:21:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ffPf4DGvsYl+wy3jOVUQPVL19LtXif+aw2VNnCRc7ic=; b=fnPkSI+/l66PxzSigLhF/pRr43Lq9JE0yLaoOh9qHDI0YBNYWolZJLXJFzD2eMQ4tv 6TJX7dIdV0G23oszJ4x5PtW0K5PLoH+X7ugRzrvz1LYRF6ykU9xga31S18TrG6ViwHHx 1N3tvOv3qdUTf5CmVKZzSakwywxdl/gPbVthqYqr+2Ae8ulIiCHht6hSimZ5BeYpjU4f j4EqgF9lHM8y+9rylOypb2bNH8h+Zz8le+7TJgZ0eKhB6qAq4GuaNW6ZO/pwVqZZ+wSq APUddzcKC5/6utap0Tgg+aX4sigPHsBn3yP9gKKRyKnsWdfaCWqH+ley0kQEwJNQh3ge KA5A== X-Gm-Message-State: ALoCoQk82M5+YyT1Exk6tSbaWt2UOZXuFMbU+xKooX/PZ4UZgMO5bq8OTaK52Pff0EqQluJpCm46 MIME-Version: 1.0 X-Received: by 10.194.92.116 with SMTP id cl20mr24569442wjb.101.1412536887208; Sun, 05 Oct 2014 12:21:27 -0700 (PDT) Received: by 10.27.94.16 with HTTP; Sun, 5 Oct 2014 12:21:27 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 15:21:27 -0400 Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: el kalin To: Brandon Vincent , Colin Percival Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net , freebsd-users@freebsd.org, freebsd-security@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 19:21:30 -0000 ok.. this is getting a bit ridiculous=E2=80=A6 just did a brand new install of the freebsd 9.3 aim on amazon=E2=80=A6 with nothing installed on it and only ssh open i get the same result when scanning with openvas: "Summary: The remote host accepts loose source routed IP packets. The feature was designed for testing purpose. An attacker may use it to circumvent poorly designed IP filtering and exploit another flaw. However, it is not dangerous by itself. Solution: drop source routed packets on this host or on other ingress routers or firewalls.' and by default: # sysctl -a | grep accept_sourceroute net.inet.ip.accept_sourceroute: 0 thing is the other machine - the bsd 10 - was scanned with the sameopen vas setup and with a service called hackerguardian offered by a compony called comodo. they sell that service as a pci compliance scan. both machines are non compliant according to both the openvas scan and the hackerguardian one=E2=80=A6 i can't be done with this job if i can't pass the pci scan=E2=80=A6 i'd appreciate any help=E2=80=A6 thanks... now what? On Sun, Oct 5, 2014 at 1:09 PM, el kalin wrote: > thanks brandon=E2=80=A6 but that didn't help=E2=80=A6. > > i still get the same result=E2=80=A6 > > i guess i'd report this as a bug=E2=80=A6 > > > On Sun, Oct 5, 2014 at 11:58 AM, Brandon Vincent > wrote: > >> On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: >> > should is submit this as a bug? >> >> Can you first try adding "set block-policy return" to pf.conf? OpenVAS >> might be assuming that a lack of response from your system to source >> routed packets is an acknowledgement that it is accepting them. >> >> Brandon Vincent >> > > From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 20:22:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95AEEC76 for ; Sun, 5 Oct 2014 20:22:30 +0000 (UTC) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 241FF668 for ; Sun, 5 Oct 2014 20:22:29 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id l18so5094128wgh.5 for ; Sun, 05 Oct 2014 13:22:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CuYTVZCEY3nuAypXPh48UTpdngNh3a/NuY+IXOhhb8s=; b=BPjsU/m51osu6YkMhUwxgjthd0FYnV8kqdopiFdtj85ziV4iolEKjbZGuq4btT2lD/ 0UNt/A6s2J7DUeZao1cEqdiG8xOB3KYoURy25OkNOwJLcYMu1ENXhimfkLfYFV/vRa3F Y4dhZv6bB87X9WvymTFwb4CuPnGKHw4YD6yZw3Eve40qwqF7O040nLIyyn2oyOvDqWSL 6CU3+4d3mzrxYTbgSRE++eZI3fz9f7XINo4sDpGbEbimXVRQLROmkibvaU/WsoiVQkE8 OQIBAqsJ9FzXBU/wwGIHaYVSOXb/hAsEgO6Cj6WnpXuYcCIgiqcN4TSE4RhI/rxcpNL5 TJtg== X-Gm-Message-State: ALoCoQmNIdi36Y6Q4GjdZEt7NG0Ye/6DvqbBlqnquKIabpsh7BiFbEMfIY1wD/zSKYwJbvwwBMcL MIME-Version: 1.0 X-Received: by 10.180.76.37 with SMTP id h5mr14766054wiw.22.1412540542072; Sun, 05 Oct 2014 13:22:22 -0700 (PDT) Received: by 10.27.94.16 with HTTP; Sun, 5 Oct 2014 13:22:22 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 16:22:22 -0400 Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: el kalin To: Brandon Vincent , Colin Percival Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net , freebsd-users@freebsd.org, freebsd-security@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 20:22:30 -0000 hmmm=E2=80=A6 could it be openvas?! just installed netbsd 6.1.4 aim i found on the aws community aims list=E2= =80=A6 same thing.. just the possibility of both openvas and the hackarguardian service being both wrong is a bit too much of a coincidence for me=E2=80=A6 any thoughts? On Sun, Oct 5, 2014 at 3:21 PM, el kalin wrote: > ok.. this is getting a bit ridiculous=E2=80=A6 > > just did a brand new install of the freebsd 9.3 aim on amazon=E2=80=A6 > > with nothing installed on it and only ssh open i get the same result when > scanning with openvas: > > "Summary: > The remote host accepts loose source routed IP packets. > The feature was designed for testing purpose. > An attacker may use it to circumvent poorly designed IP filtering > and exploit another flaw. However, it is not dangerous by itself. > Solution: > drop source routed packets on this host or on other ingress > routers or firewalls.' > > and by default: > # sysctl -a | grep accept_sourceroute > net.inet.ip.accept_sourceroute: 0 > > thing is the other machine - the bsd 10 - was scanned with the sameopen > vas setup and with a service called hackerguardian offered by a compony > called comodo. they sell that service as a pci compliance scan. both > machines are non compliant according to both the openvas scan and the > hackerguardian one=E2=80=A6 > > i can't be done with this job if i can't pass the pci scan=E2=80=A6 > > i'd appreciate any help=E2=80=A6 > > thanks... > > > now what? > > > > > > > On Sun, Oct 5, 2014 at 1:09 PM, el kalin wrote: > >> thanks brandon=E2=80=A6 but that didn't help=E2=80=A6. >> >> i still get the same result=E2=80=A6 >> >> i guess i'd report this as a bug=E2=80=A6 >> >> >> On Sun, Oct 5, 2014 at 11:58 AM, Brandon Vincent > > wrote: >> >>> On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: >>> > should is submit this as a bug? >>> >>> Can you first try adding "set block-policy return" to pf.conf? OpenVAS >>> might be assuming that a lack of response from your system to source >>> routed packets is an acknowledgement that it is accepting them. >>> >>> Brandon Vincent >>> >> >> > From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 20:59:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1E5CEB6 for ; Sun, 5 Oct 2014 20:59:21 +0000 (UTC) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7401A26 for ; Sun, 5 Oct 2014 20:59:21 +0000 (UTC) Received: by mail-yh0-f48.google.com with SMTP id v1so1548255yhn.21 for ; Sun, 05 Oct 2014 13:59:20 -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=PI3wM2SMc/FJhbhfAoB8gUgKNNc6b+AXC1SFFZVh/I0=; b=EiJ3cqy62Tj15141d0FOvG9SDu0srDUBUtBjC0HxoaRoTfJTI3lP5dD5nCmi8kk/8x N/wgvkLdicfT5urno8qb8lPQYaEPVjDY+QZZqi/16zPUHOR0F6m1YOZXrQHtcf7of1lM 0jTb3Rf1+X/fCi86t4aQVrBgw783DpddWjMrbShr3wC3G4holTZnqXPIjikKsEJfn91F i0nqdrum6upsa/KiHh5r2xJmKjK0vTsHlII0PYyP4gKPj1SZAFYviXnnsAxaulwSBD69 NVeuQW0UhJqs0ffHQz36n1fIeCZ9K52ml8uUNtfDR2bAWOUr59+pkww9DwvUF/2jOEBu OeXA== MIME-Version: 1.0 X-Received: by 10.236.37.36 with SMTP id x24mr30494784yha.19.1412542760813; Sun, 05 Oct 2014 13:59:20 -0700 (PDT) Received: by 10.170.75.136 with HTTP; Sun, 5 Oct 2014 13:59:20 -0700 (PDT) Date: Sun, 5 Oct 2014 23:59:20 +0300 Message-ID: Subject: [patch] ipv6 prefix lifetime is not updated when address is updated through SIOCAIFADDR_IN6 From: Guy Yur To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=089e0115ec327d2d550504b33de8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 20:59:22 -0000 --089e0115ec327d2d550504b33de8 Content-Type: text/plain; charset=UTF-8 Hi, I am running dhcpcd 6.4.3 on 11.0-CURRENT r271879M to get an ipv6 prefix from my ISP. The prefix is received with a lifetime of 86400 seconds. dhcpcd adds an address using the prefix with pltime and vltime of 86400. Before the address expires dhcpcd refreshes it but the interface route for the prefix is still deleted after 86400 seconds. dhcpcd uses SIOCAIFADDR_IN6 to update the address and the kernel doesn't update the prefix lifetime if the prefix already exists. Since ndpr_lastupdate is also not updated the prefix will expire. The issue doesn't happen when updating lifetime using ifconfig with pltime and vltime since ifconfig removes the address before adding it (each ifconfig invocation will reset the prefix lifetime). I created a patch to update the prefix lifetimes in SIOCAIFADDR_IN6 from the added address's lifetime. If there are two addresses with same prefix but different lifetimes it means the last one added will set the prefix lifetime. Another way will be to move the check in SIOCAIFADDR_IN6 to a new function nd6_prelist_update that will call nd6_prefix_lookup. If the prefix doesn't exist, call nd6_prelist_add. If it does exist, copy lifetimes (and ndpr_flags?). Before: # netstat -rn -f inet6 WWWW:XXXX:YYYY:ZZZZ::/64 link#1 U lan0 WWWW:XXXX:YYYY:ZZZZ::1 link#1 UHS lo0 ... After more than 86400 seconds: # ifconfig -L lan0 inet6 lan0: flags=8843 metric 0 mtu 1500 options=8000b inet6 fe80::AAAA:BBBB:CCCC:DDDD%lan0 prefixlen 64 scopeid 0x1 inet6 WWWW:XXXX:YYYY:ZZZZ::1 prefixlen 64 pltime 57257 vltime 57257 nd6 options=21 # ndp -p WWWW:XXXX:YYYY:ZZZZ::/64 if=lan0 flags=L vltime=0, pltime=0, expired, ref=1 No advertising router ... # netstat -rn -f inet6 WWWW:XXXX:YYYY:ZZZZ::1 link#1 UHS lo0 ... Regards, Guy --089e0115ec327d2d550504b33de8 Content-Type: application/octet-stream; name="update_prefix_ltimes.patch" Content-Disposition: attachment; filename="update_prefix_ltimes.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i0wuwjfx0 SW5kZXg6IHN5cy9uZXRpbmV0Ni9pbjYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldDYvaW42 LmMJKHJldmlzaW9uIDI3MjU2NikKKysrIHN5cy9uZXRpbmV0Ni9pbjYuYwkod29ya2luZyBjb3B5 KQpAQCAtNjc4LDYgKzY3OCw4IEBAIGluNl9jb250cm9sKHN0cnVjdCBzb2NrZXQgKnNvLCB1X2xv bmcgY21kLCBjYWRkcl90CiAJCQkJZ290byBvdXQ7CiAJCQl9CiAJCX0KKwkJZWxzZQorCQkJbmQ2 X3ByZWZpeF91cGRhdGVfbHRpbWVzKHByLCAmcHIwKTsKIAogCQkvKiByZWxhdGUgdGhlIGFkZHJl c3MgdG8gdGhlIHByZWZpeCAqLwogCQlpZiAoaWEtPmlhNl9uZHByID09IE5VTEwpIHsKSW5kZXg6 IHN5cy9uZXRpbmV0Ni9uZDYuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldDYvbmQ2LmgJKHJl dmlzaW9uIDI3MjU2NikKKysrIHN5cy9uZXRpbmV0Ni9uZDYuaAkod29ya2luZyBjb3B5KQpAQCAt NDQ1LDYgKzQ0NSw3IEBAIGludCBuZDZfcHJlbGlzdF9hZGQoc3RydWN0IG5kX3ByZWZpeGN0bCAq LCBzdHJ1Y3QKIHZvaWQgcGZ4bGlzdF9vbmxpbmtfY2hlY2sodm9pZCk7CiBzdHJ1Y3QgbmRfZGVm cm91dGVyICpkZWZyb3V0ZXJfbG9va3VwKHN0cnVjdCBpbjZfYWRkciAqLCBzdHJ1Y3QgaWZuZXQg Kik7CiBzdHJ1Y3QgbmRfcHJlZml4ICpuZDZfcHJlZml4X2xvb2t1cChzdHJ1Y3QgbmRfcHJlZml4 Y3RsICopOworaW50IG5kNl9wcmVmaXhfdXBkYXRlX2x0aW1lcyhzdHJ1Y3QgbmRfcHJlZml4ICos IHN0cnVjdCBuZF9wcmVmaXhjdGwgKik7CiB2b2lkIHJ0Nl9mbHVzaChzdHJ1Y3QgaW42X2FkZHIg Kiwgc3RydWN0IGlmbmV0ICopOwogaW50IG5kNl9zZXRkZWZhdWx0aWZhY2UoaW50KTsKIGludCBp bjZfdG1waWZhZGQoY29uc3Qgc3RydWN0IGluNl9pZmFkZHIgKiwgaW50LCBpbnQpOwpJbmRleDog c3lzL25ldGluZXQ2L25kNl9ydHIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldDYvbmQ2X3J0 ci5jCShyZXZpc2lvbiAyNzI1NjYpCisrKyBzeXMvbmV0aW5ldDYvbmQ2X3J0ci5jCSh3b3JraW5n IGNvcHkpCkBAIC04NTMsNiArODUzLDIxIEBAIG5kNl9wcmVmaXhfbG9va3VwKHN0cnVjdCBuZF9w cmVmaXhjdGwgKmtleSkKIH0KIAogaW50CituZDZfcHJlZml4X3VwZGF0ZV9sdGltZXMoc3RydWN0 IG5kX3ByZWZpeCAqcHIsIHN0cnVjdCBuZF9wcmVmaXhjdGwgKnByY3RsKQoreworCWludCBlcnJv cjsKKworCXByLT5uZHByX3ZsdGltZSA9IHByY3RsLT5uZHByX3ZsdGltZTsKKwlwci0+bmRwcl9w bHRpbWUgPSBwcmN0bC0+bmRwcl9wbHRpbWU7CisJaWYgKChlcnJvciA9IGluNl9pbml0X3ByZWZp eF9sdGltZXMocHIpKSAhPSAwKSB7CisJCXJldHVybiAoZXJyb3IpOworCX0KKwlwci0+bmRwcl9s YXN0dXBkYXRlID0gdGltZV91cHRpbWU7CisKKwlyZXR1cm4gMDsKK30KKworaW50CiBuZDZfcHJl bGlzdF9hZGQoc3RydWN0IG5kX3ByZWZpeGN0bCAqcHIsIHN0cnVjdCBuZF9kZWZyb3V0ZXIgKmRy LAogICAgIHN0cnVjdCBuZF9wcmVmaXggKipuZXdwKQogewo= --089e0115ec327d2d550504b33de8-- From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 21:00:27 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ED4A1C6 for ; Sun, 5 Oct 2014 21:00:27 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71CB1AB5 for ; Sun, 5 Oct 2014 21:00:27 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s95L0R0W012973 for ; Sun, 5 Oct 2014 21:00:27 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201410052100.s95L0R0W012973@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 05 Oct 2014 21:00:27 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 21:00:27 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ----------------+-----------+------------------------------------------------- Needs MFC | 183659 | [tcp] TCP stack lock contention with short-live 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Sun Oct 5 21:40:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 484E7446; Sun, 5 Oct 2014 21:40:00 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63CACE59; Sun, 5 Oct 2014 21:39:59 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id m15so5102854wgh.28 for ; Sun, 05 Oct 2014 14:39: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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=qmq0KGmznDJEZR5UsstdQ+O1itetFOfOCV0DlaAc0aM=; b=Z5vHLGPi1DKqxmdNjK6ji/1bryAv1bhO5Cc7XZVidoHz70t9Q7EJMVdKI2fC9OWbEI GIJAi2TXXodGA2TyMW7XSRKkuXN7iYyEKPg7DWktKh/ZzPiMMv5qErNThB5xfbMMrIzC xOSEYa9zBN44bQ5BmUkRnMkMaN9hBOpID/0h/V3OoNQROGftyYDqnF5+7HSXEqm4wF3U Sh3PzFOygEQqj71utcRR2CkEZI9pyFD4qsLn8xG5hUUAEolywm5Hrd1QmbdASE41z9U+ 2ds8higw1/TGy6VaZ/i0r9AoETxo6/k57PfMvvVROxbPUJ1CD+0Jm+W7f9gQE0H8Ufpn 8S+Q== MIME-Version: 1.0 X-Received: by 10.180.97.98 with SMTP id dz2mr14918530wib.26.1412545197757; Sun, 05 Oct 2014 14:39:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sun, 5 Oct 2014 14:39:57 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 14:39:57 -0700 X-Google-Sender-Auth: x2K3Vud6rqBYuU5eggVo3Ou6nEM Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: Adrian Chadd To: el kalin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, freebsd-net , freebsd-users@freebsd.org, Colin Percival , Brandon Vincent X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 21:40:00 -0000 Hi, Can you please get a packet capture of what it's sending and what it's receiving? All accept_sourceroute does is prevent the stack from forwarding source routed packets. If it's destined locally then it's still accepted. You could try crafting an ipfw rule to filter out packets with these options set: from man ipfw: ipoptions spec Matches packets whose IPv4 header contains the comma separated list of options specified in spec. The supported IP options a= re: ssrr (strict source route), lsrr (loose source route), rr (rec= ord packet route) and ts (timestamp). The absence of a particular option may be denoted with a `!'. something like: 1 deny ip from any to any ipoptions ssrr,lsrr,rr 65000 allow ip from any to any -a On 5 October 2014 13:22, el kalin wrote: > hmmm=E2=80=A6 could it be openvas?! > > just installed netbsd 6.1.4 aim i found on the aws community aims list=E2= =80=A6 > same thing.. > > just the possibility of both openvas and the hackarguardian service being > both wrong is a bit too much of a coincidence for me=E2=80=A6 > > any thoughts? > > > > > On Sun, Oct 5, 2014 at 3:21 PM, el kalin wrote: > >> ok.. this is getting a bit ridiculous=E2=80=A6 >> >> just did a brand new install of the freebsd 9.3 aim on amazon=E2=80=A6 >> >> with nothing installed on it and only ssh open i get the same result whe= n >> scanning with openvas: >> >> "Summary: >> The remote host accepts loose source routed IP packets. >> The feature was designed for testing purpose. >> An attacker may use it to circumvent poorly designed IP filtering >> and exploit another flaw. However, it is not dangerous by itself. >> Solution: >> drop source routed packets on this host or on other ingress >> routers or firewalls.' >> >> and by default: >> # sysctl -a | grep accept_sourceroute >> net.inet.ip.accept_sourceroute: 0 >> >> thing is the other machine - the bsd 10 - was scanned with the sameopen >> vas setup and with a service called hackerguardian offered by a compony >> called comodo. they sell that service as a pci compliance scan. both >> machines are non compliant according to both the openvas scan and the >> hackerguardian one=E2=80=A6 >> >> i can't be done with this job if i can't pass the pci scan=E2=80=A6 >> >> i'd appreciate any help=E2=80=A6 >> >> thanks... >> >> >> now what? >> >> >> >> >> >> >> On Sun, Oct 5, 2014 at 1:09 PM, el kalin wrote: >> >>> thanks brandon=E2=80=A6 but that didn't help=E2=80=A6. >>> >>> i still get the same result=E2=80=A6 >>> >>> i guess i'd report this as a bug=E2=80=A6 >>> >>> >>> On Sun, Oct 5, 2014 at 11:58 AM, Brandon Vincent >> > wrote: >>> >>>> On Sun, Oct 5, 2014 at 8:33 AM, el kalin wrote: >>>> > should is submit this as a bug? >>>> >>>> Can you first try adding "set block-policy return" to pf.conf? OpenVAS >>>> might be assuming that a lack of response from your system to source >>>> routed packets is an acknowledgement that it is accepting them. >>>> >>>> Brandon Vincent >>>> >>> >>> >> > _______________________________________________ > 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 Sun Oct 5 22:24:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A2BC1DD for ; Sun, 5 Oct 2014 22:24:25 +0000 (UTC) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8F01365 for ; Sun, 5 Oct 2014 22:24:24 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id f51so3053383qge.14 for ; Sun, 05 Oct 2014 15:24:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eEDz4giwue9VhfcVCvqrYJI1pvhseDvTLztlrb2APzs=; b=hzqj9/S1E8UctWYL4fLpgYvy6QVpbko8FjLEcvz7IYOkNOkfhzPtjDbqeHJ46Xp86+ GBkuu6yAcubHFuObYkmPmqTV7t0h2hte2jsYZt/RBbcd69Ld9G+0N7wsIfKCMsR17qv0 SkThpZWi1xahtpkUl/9ab952siLf54K6wixjMNjt4fABYFPe4GUiaatdr8Wam97/QtTX gwThYTXpitQ8+Vr1G77xBGaI+BSMURU+3BmghyLR8R52IHG2yV/paeoxLg3n4JTzqDw2 GZ08xQvqHyb+O9p7BMGRwwqFZ8JxMgD9Hg6RipscPJIfaaB34TnBzpZvB7rih1JWhk62 8K2w== X-Gm-Message-State: ALoCoQl/p/GyWm2daqgZPRmr8ne3A7zg4ZA3pMkKRkY3JsNMFlg0PQ2/uOBf9tYqd4SMIWuSPOvo MIME-Version: 1.0 X-Received: by 10.140.32.36 with SMTP id g33mr22560779qgg.57.1412547857924; Sun, 05 Oct 2014 15:24:17 -0700 (PDT) Received: by 10.140.95.193 with HTTP; Sun, 5 Oct 2014 15:24:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 15:24:17 -0700 Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: Brandon Vincent To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net , el kalin , freebsd-users@freebsd.org, Colin Percival , freebsd-security@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 05 Oct 2014 22:24:25 -0000 On Sun, Oct 5, 2014 at 2:39 PM, Adrian Chadd wrote: > All accept_sourceroute does is prevent the stack from forwarding > source routed packets. If it's destined locally then it's still > accepted. Out of curiosity, isn't "net.inet.ip.accept_sourceroute" supposed to reject incoming source routed packets? On 5 October 2014 13:22, el kalin wrote: > hmmm=E2=80=A6 could it be openvas?! OpenVAS is a fork of Nessus from when it was open source. HackerGuardian seems to use Nessus as the chief scanning engine. Brandon Vincent From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 00:56:25 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D85BF8E9; Mon, 6 Oct 2014 00:56:25 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEA7330C; Mon, 6 Oct 2014 00:56:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=+7UMKAiqJFV/RI4PZZYQ3LYPK9zcLgFryw4O2OrKgkg=; b=Y23houYCS4Ge/Sxi0zPkFSNDWeAqfB3usm6TTkJAr3eflXs7Qz2LlA7FZ2YaJoXW03JqkCwJ3PkA67/AZPPoXej6JUKFSnmmh/GjIPeyxVuZ8YdmiMTQAq7vLt3j6jfXp8xVPGQ89tYtuwlkLkqaezPVagVSs5D0p/qd1kNXPII=; Received: from [182.1.193.13] (port=23547 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xawb4-003GY4-JX; Sun, 05 Oct 2014 18:56:19 -0600 Date: Mon, 6 Oct 2014 08:56:06 +0800 From: Erich Dollansky To: Scot Hetzel Subject: Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails Message-ID: <20141006085606.1d55fe5e@X220.alogt.com> In-Reply-To: References: <20141005013247.GH1171@hub.FreeBSD.org> <20141005203401.440afc31@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Glen Barber , freebsd-jail@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Stable , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 00:56:26 -0000 Hi, On Sun, 5 Oct 2014 11:38:47 -0500 Scot Hetzel wrote: > On Sun, Oct 5, 2014 at 7:34 AM, Erich Dollansky > wrote: > > On Sat, 4 Oct 2014 21:32:47 -0400 > > Glen Barber wrote: > > > >> The first RC build of the 10.1-RELEASE release cycle is now > >> available > > > > I installed this shortly after your e-mail came. The result was the > > same as with BETA3. If you remember, I have had the problem that the > > network inside jails stopped working after I installed BETA3. The > > upgrade to RC1 did not change anything. > > > You'll need to identify where in the src caused the issue for you. To > do this, you will need to identify where it was working (BETA1?). > You would then have to step thru the sources until you find the point > where it breaks. > > The easiest way would be to take the svn revision that is half way > between BETA1 and BETA3, compile and install it and see if it works. > You keep halving the result until you identify the commit that broke > it. > > Once the offending commit is identified, email the list. > this is what I wanted to avoid. A shame that -Dno_clean will not work here. It would save a lot of compile time without running the risk missing out some files. Anyway, I compile world and kernel just to make sure that the problem is caught. This will take some time. Erich From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 02:26:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83F12F9A; Mon, 6 Oct 2014 02:26:40 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70561C07; Mon, 6 Oct 2014 02:26:39 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id cc10so3226573wib.7 for ; Sun, 05 Oct 2014 19:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=24XaLrHVTJ+lAOxAwwAMMYZOAzuJt9+Bo+/S3T37Jjc=; b=pSzAUlyG8OR+w3qV8PRbJp+IKgKibDSDuA7mnUe5Ny8g2F9/IwhPQ/TRRPxn7SfeR3 Izuo+eZ1z8ckm9OfcOTK1hNLZzA41F9bjvXrwQpHQmXIfk2VsbLWFKm13fuhxyKBrMpl tFnNU3T9tGO/ip3L+D6N6QW6Z0NN6Vau/B58BDp5YCaBTy972hqvxJtLvploNBFzQRFL chxbOPhfJJ4hiU2f91lxgN4lyqXNyNFQITlj1KhNBGxNboxsFm0HUmzYniYKIuTXT8fE DEXLZRWiNNx0fBPu5+vUT/zk7JoQpclVqz5NAQQ+pdEwlkxLPMtIYwj15w+91GeS76Dr VWPw== MIME-Version: 1.0 X-Received: by 10.180.103.131 with SMTP id fw3mr15792406wib.77.1412562397684; Sun, 05 Oct 2014 19:26:37 -0700 (PDT) Received: by 10.216.159.193 with HTTP; Sun, 5 Oct 2014 19:26:37 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <542FE9A7.9090208@FreeBSD.org> References: <542FE9A7.9090208@FreeBSD.org> Date: Mon, 6 Oct 2014 10:26:37 +0800 Message-ID: Subject: Re: HEADS UP: Merging projects/ipfw to HEAD From: Marcelo Araujo To: "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-current , freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 02:26:40 -0000 Hey Alexander, Very nice work, thank you so much to bring these stuff to us. Best Regards, 2014-10-04 20:35 GMT+08:00 Alexander V. Chernikov : > Hi, > > I'm going to merge projects/ipfw branch to HEAD in the middle of next week. > > What has changed: > > Main user-visible changes are related to tables: > > * Tables are now identified by names, not numbers. There can be up to 65k > tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them > atomically with rules. > * More functionality is supported (swap, lock, limits, user-level lookup, > batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet fields > at once. > * Ability to add different type of lookup algorithms for particular table > type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array and > flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for > different tablearg users > > Some examples (see ipfw(8) manual page for the description): > > 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port > algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 > flow 'table(fl2)' > > ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 > > # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 > added: 1.1.1.1/32 1111 > added: 2.2.2.2/32 2222 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 4444 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 1111 > 2.2.2.2/32 2222 > 4.4.4.4/32 4444 > # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 5.5.5.5/32 > 5555 > added(reverted): 3.3.3.3/32 3333 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 5555 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error and reverts added records > > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 bytes > * interface tables uses array of existing ifindexes for faster match > > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & new > binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset in > old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something may > be broken here. Anyway, this can be fixed for MFC > > Internal changes:. > Changing table ids to numbers resulted in format modification for most > sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, > inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned IP_FW3-based > codes. > * The remaining opcodes were also converted to be able to eliminate all > older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* > directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds > extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit > effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time (eats > 512K). > > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and > actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct > ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 06:23:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 319B8AAE for ; Mon, 6 Oct 2014 06:23:00 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3DB65FD for ; Mon, 6 Oct 2014 06:22:59 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id cc10so3480575wib.17 for ; Sun, 05 Oct 2014 23:22:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OEqOrOrmnl348YeegQyST0ZiiNIRMkCncBrSWAamF0s=; b=aLPMlhEQ56MRiIE0SbCrmsyHvefjIxJN4FZ3k2CKdIUHWqMcUiEc7JlKR6XrlISj5I L1xaWwvpPAaMxi6d6hKvyyxdwX7hAfaKK0TwG8P9HlPy+abPX+OafvVc33WZAelzkHsv gOke9fBy6/PFOXtQ3s4f87eCkhx8OYBilx0d5T4S8aMKxqyRIglrB+UAmrT/Xpaf1YKY 3IokipJaH/aIEGFNThfnuUBN4Q65Er7skKNIKKVSlMEg/Q/MktE4VNRQ+EUgaVQ29USO cyu9CFfmvAxP6w1FtUreAkwnXoGJ11rDrAYa9ASO36cv5zZ2Tn85tfdBe5DKWB2RevHI B2/Q== X-Gm-Message-State: ALoCoQmaQMRY2PGRuzxreRnlRqhoqnivJvU2g/7NLD8P4ywXH8AJqanlSFi6EFN0Bo8wUMR7xueX MIME-Version: 1.0 X-Received: by 10.194.246.2 with SMTP id xs2mr26357122wjc.33.1412576245906; Sun, 05 Oct 2014 23:17:25 -0700 (PDT) Received: by 10.27.94.16 with HTTP; Sun, 5 Oct 2014 23:17:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Oct 2014 02:17:25 -0400 Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: el kalin To: Brandon Vincent Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-net , Adrian Chadd , freebsd-users@freebsd.org, Colin Percival , freebsd-security@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 06:23:00 -0000 On Sun, Oct 5, 2014 at 6:24 PM, Brandon Vincent wrote: > On Sun, Oct 5, 2014 at 2:39 PM, Adrian Chadd wrote: > > All accept_sourceroute does is prevent the stack from forwarding > > source routed packets. If it's destined locally then it's still > > accepted. > > Out of curiosity, isn't "net.inet.ip.accept_sourceroute" supposed to > reject incoming source routed packets? that was my understanding too. as far a forwarding - have it off too: # sysctl -a | grep forwa kern.smp.forward_signal_enabled: 1 net.inet.ip.forwarding: 0 net.inet.ip.fastforwarding: 0 net.inet6.ip6.forwarding: 0 > > On 5 October 2014 13:22, el kalin wrote: > > hmmm=E2=80=A6 could it be openvas?! > > OpenVAS is a fork of Nessus from when it was open source. > HackerGuardian seems to use Nessus as the chief scanning engine. i'm aware of those. i used to use Nessus when it was open and did pre scanning for pci with it on freebsd 7 and 8 and everything was fine. now this is really mind boggling=E2=80=A6. i can't imagine that both freebsd 9 an 10 and also netbsd 6 will have this "vulnerability" which according to the information that the hackerguardian (nessus?!) suggest to read points to links from 2002. unless it has to do with virtualization somehow. am i the first person ever to try to get pci compliant on bsd on aws?! i did report this as a false positive to hackerguardian on friday. haven't heard from them since. but i'm not holding my breath=E2=80=A6 > > Brandon Vincent > From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 06:24:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 222E7B3F; Mon, 6 Oct 2014 06:24:13 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AA35619; Mon, 6 Oct 2014 06:24:12 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x13so5609947wgg.6 for ; Sun, 05 Oct 2014 23:24:10 -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:message-id:subject :from:to:cc:content-type; bh=/YA8yMSP4Int3LA7Kn2SwulM0Qmj45lf4vgFaMkbEaU=; b=d59a83fy9RO7xCC4SpKZtp+4a8GYOg2g9CSr/z4X8XMYFt7NXLPDXhuwaL38LMAwNa upqrBUgKP9ryHJut3UftKmDjiVBCMAyCS83nSqz6po2PnEXuP2EW4TNCW4N8dYW6PCbU 7rRGgqFjklb21fZ+0KrcyTO80MlNDSFy9FVakHjCyCF7IXvOCHPc5J+NF5CzwQT5fiaF ltz3JzsvED6rv2LndyGkq1IfVNR6Attyj6ouXE/92tptoL6wd2h+3eF8K15gnmhInCi5 E8Mz6UXOC6wDbN0NHb3afyeyI4EBFpa2jWzfJoVzgeGkrwRMgyJa4Z4ihGjGlYIThvP4 ikKg== MIME-Version: 1.0 X-Received: by 10.194.157.230 with SMTP id wp6mr27408459wjb.15.1412576650395; Sun, 05 Oct 2014 23:24:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sun, 5 Oct 2014 23:24:10 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Oct 2014 23:24:10 -0700 X-Google-Sender-Auth: XuPU46rKcwBzVUM0gswP46xnHTU Message-ID: Subject: Re: remote host accepts loose source routed IP packets From: Adrian Chadd To: el kalin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org, freebsd-net , Colin Percival , Brandon Vincent X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 06:24:13 -0000 Hi, I'm just going off what I saw in the code. Maybe the code changed and the bug was introduced. I suggest: (a) use ipfw to filter them for now; and (b) file a PR (https://bugs.freebsd.org/submit/) so it's not forgotten. Thanks! -a From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 08:00:11 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0ADF34E for ; Mon, 6 Oct 2014 08:00:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A5A38F77 for ; Mon, 6 Oct 2014 08:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9680Bwn053759 for ; Mon, 6 Oct 2014 08:00:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201410060800.s9680Bwn053759@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [FreeBSD Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 06 Oct 2014 08:00:11 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 08:00:11 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (1 bugs) Bug 183659: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183659 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-net@FreeBSD.org Status: Needs MFC Resolution: Summary: [tcp] TCP stack lock contention with short-lived connections From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 11:00:51 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB302F09 for ; Mon, 6 Oct 2014 11:00:51 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3A968EB for ; Mon, 6 Oct 2014 11:00:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s96B0px7083803 for ; Mon, 6 Oct 2014 11:00:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 179733] [lagg] [patch] interface loses capabilities when protocol changes Date: Mon, 06 Oct 2014 11:00:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: garga@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 11:00:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179733 Renato Botelho changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |Overcome By Events --- Comment #2 from Renato Botelho --- It works fine on 11-current -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 11:31:20 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88732B59; Mon, 6 Oct 2014 11:31:20 +0000 (UTC) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25951B7F; Mon, 6 Oct 2014 11:31:19 +0000 (UTC) Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo04.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id 88d72345.2b221ac7d940.1390574.00-2472.3550500.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 06 Oct 2014 11:31:20 +0000 (UTC) X-MXL-Hash: 54327d88159f6782-1f601796ccc619fa39a348cc8d8c0ee2fef6268f Received: from unknown [12.187.104.25] (EHLO webmail.solarflare.com) by nbfkord-smmo04.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id 08d72345.0.1390568.00-2324.3550477.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 06 Oct 2014 11:31:18 +0000 (UTC) X-MXL-Hash: 54327d86511cbff2-652b70ef941a2838a1bcad4471d8d09d273d52e9 Received: from ocex03.SolarFlarecom.com (10.20.40.36) by ocex02.SolarFlarecom.com (10.20.40.31) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Oct 2014 04:30:33 -0700 Received: from [192.168.38.17] (84.52.89.52) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 6 Oct 2014 04:30:50 -0700 Message-ID: <54327D5D.6010904@solarflare.com> Date: Mon, 6 Oct 2014 15:30:37 +0400 From: Andrew Rybchenko User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Baldwin , Subject: Re: Choice of private ioctl approach References: <54295246.6010502@solarflare.com> <201409301131.31309.jhb@freebsd.org> In-Reply-To: <201409301131.31309.jhb@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [84.52.89.52] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ocex03.SolarFlarecom.com (10.20.40.36) X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20998.005 X-TM-AS-Result: No--14.978200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.0 cv=CYa/EsXl c=1 sm=1 a=MkjXnYnS3dyNWGSWLXxFFQ==:17 a] X-AnalysisOut: [=Ozv50jBIw7UA:10 a=4oxowH2qkH0A:10 a=RB3BGLmKESwA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zRKbQ67AAAAA:8 a=P3e8OJEo] X-AnalysisOut: [HGnXFEymnLsA:9 a=wPNLvfGTeEIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [12.187.104.25] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 11:31:20 -0000 Hello John, On 09/30/2014 07:31 PM, John Baldwin wrote: > On Monday, September 29, 2014 8:36:22 am Andrew Rybchenko wrote: >> Hello, >> >> we need to add private ioctl to the driver sfxge(4) to make FW update, >> do internal diagnostics commands etc. >> We see at least two approaches in other drivers: >> 1. SIOCGPRIVATE_0/ SIOCGPRIVATE_1 on net device >> 2. dedicated char device with its own ioctl's >> >> Is there any recommendations on which way is preferred? > I would be inclined towards 2). It is more flexible if you need to add m= ore > custom ioctls in the future. Thanks a lot for your reply. It looks like there are no any strong opinions on the topic. The problem with 2) is that it adds one more entity and we'd like to avoid it. We need more than one request semantically, so we'll have multiplexing by internal opcode inside SIOCGPRIVATE_0. I think it is flexible enough. Best regards, Andrew. The information contained in this message is confidential and is intended f= or the addressee(s) only. If you have received this message in error, pleas= e notify the sender immediately and delete the message. Unless you are an a= ddressee (or authorized to receive for an addressee), you may not use, copy= or disclose to anyone this message or any information contained in this me= ssage. The unauthorized use, disclosure, copying or alteration of this mess= age is strictly prohibited. From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 16:38:09 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 831BC5A7; Mon, 6 Oct 2014 16:38:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 595386CD; Mon, 6 Oct 2014 16:38:09 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C3D23B949; Mon, 6 Oct 2014 12:38:07 -0400 (EDT) From: John Baldwin To: "Robert N. M. Watson" Subject: Re: [PATCH] Only lock send buffer in sopoll() if needed Date: Mon, 06 Oct 2014 12:37:42 -0400 Message-ID: <1527564.dunJKn8zWW@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <9DED9207-89B7-47C3-B823-047A5FDFC511@FreeBSD.org> References: <201409301400.09999.jhb@freebsd.org> <9DED9207-89B7-47C3-B823-047A5FDFC511@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Oct 2014 12:38:07 -0400 (EDT) Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 16:38:09 -0000 On Sunday, October 05, 2014 08:08:17 AM Robert N. M. Watson wrote: > I'm not convinced that the race with SBS_CANTSENDMORE is OK, even though I > really want to write that it is. The risk here is that we miss an > asynchronous disconnect event, and that the thread then blocks even though > an event is pending, which is a nasty turn of events. We might want to dig > about a bit and see whether this case 'matters' -- e.g., that there are > important cases where a test for writability might need to catch > SBS_CANTRCVMORE but SBS_CANTSENDMORE is not simultaneously set. I thought about this a bit more and this would be ok so long as the code that does a selwakeup() on so_rcv does so after setting SBS_CANTSENDMORE. However, checking both soisdisconnecting() and soisdisconnected() shows that they call sorwakeup() and unlock the sb_rcv lock before setting the flag, so the race is not ok. > Could you say a bit more about the performance benefits of this change -- is > it substantial? If so, we might need to add a new socket-buffer flag along > the lines of SB[RS]_DISCONNECTED that is 'broadcast' to both socket buffers > on certain events. Doing so might require rejiggering elsewhere by causing > additional locks to need to be held, possibly out of order. I had posted this to an older thread on current@ where Luigi asked about the overhead of locking both for sopoll(). I never got a reply from Luigi (and no one else responded on that thread). I found this again recently in an old tree and was curious what other folks thought of the idea. I do not have any workloads I am working with where this is a factor. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 17:52:01 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA2F2EFB for ; Mon, 6 Oct 2014 17:52:01 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91831F63 for ; Mon, 6 Oct 2014 17:52:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s96Hq11P058777 for ; Mon, 6 Oct 2014 17:52:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Mon, 06 Oct 2014 17:52:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dan_256@yahoo.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 17:52:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #14 from Dan --- I think a patch like the following would make using legacy mode easier. This one is for IGB, but a similar one would work for IXGBE: Index: sys/conf/options =================================================================== --- sys/conf/options (revision 272659) +++ sys/conf/options (working copy) @@ -405,6 +405,7 @@ ETHER_8023 opt_ef.h ETHER_II opt_ef.h ETHER_SNAP opt_ef.h +IGB_LEGACY_TX opt_igb.h INET opt_inet.h INET6 opt_inet6.h IPDIVERT Index: sys/dev/e1000/if_igb.c =================================================================== --- sys/dev/e1000/if_igb.c (revision 272659) +++ sys/dev/e1000/if_igb.c (working copy) @@ -33,6 +33,8 @@ /*$FreeBSD$*/ +#include "opt_igb.h" + #include "opt_inet.h" #include "opt_inet6.h" Index: sys/dev/e1000/if_igb.h =================================================================== --- sys/dev/e1000/if_igb.h (revision 272659) +++ sys/dev/e1000/if_igb.h (working copy) @@ -35,6 +35,8 @@ #ifndef _IGB_H_DEFINED_ #define _IGB_H_DEFINED_ +#include "opt_igb.h" + /* Tunables */ /* -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 17:56:59 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4A162FD for ; Mon, 6 Oct 2014 17:56:59 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7389AFBA for ; Mon, 6 Oct 2014 17:56:59 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s96Hux9O076640 for ; Mon, 6 Oct 2014 17:56:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Mon, 06 Oct 2014 17:56:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ncrogers@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 17:56:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #15 from ncrogers@gmail.com --- (In reply to Dan from comment #14) > I think a patch like the following would make using legacy mode easier. > This one is for IGB, but a similar one would work for IXGBE: I think thats a good idea and something that I've requested in the past. I am not sure if there is an existing PR for it or not. Can you please start a new PR/bug in regards to making IGB/IXGBE LEGACY a kernel option? I would like to keep this bug focussed on fixing the IXGBE_LEGACY_TX path which currently doesn't even compile. Thanks. > > Index: sys/conf/options > =================================================================== > --- sys/conf/options (revision 272659) > +++ sys/conf/options (working copy) > @@ -405,6 +405,7 @@ > ETHER_8023 opt_ef.h > ETHER_II opt_ef.h > ETHER_SNAP opt_ef.h > +IGB_LEGACY_TX opt_igb.h > INET opt_inet.h > INET6 opt_inet6.h > IPDIVERT > Index: sys/dev/e1000/if_igb.c > =================================================================== > --- sys/dev/e1000/if_igb.c (revision 272659) > +++ sys/dev/e1000/if_igb.c (working copy) > @@ -33,6 +33,8 @@ > /*$FreeBSD$*/ > > > +#include "opt_igb.h" > + > #include "opt_inet.h" > #include "opt_inet6.h" > > Index: sys/dev/e1000/if_igb.h > =================================================================== > --- sys/dev/e1000/if_igb.h (revision 272659) > +++ sys/dev/e1000/if_igb.h (working copy) > @@ -35,6 +35,8 @@ > #ifndef _IGB_H_DEFINED_ > #define _IGB_H_DEFINED_ > > +#include "opt_igb.h" > + > /* Tunables */ > > /* -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 18:17:25 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0E7BD4A for ; Mon, 6 Oct 2014 18:17:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 985212BB for ; Mon, 6 Oct 2014 18:17:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s96IHPHf067555 for ; Mon, 6 Oct 2014 18:17:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 193053] ixgbe(4) IXGBE_LEGACY_TX + ALTQ path broken Date: Mon, 06 Oct 2014 18:17:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dan_256@yahoo.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 18:17:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193053 --- Comment #16 from Dan --- I submitted the following bug. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194197 I added code to enable IXGBE as well; hopefully it was correct. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Mon Oct 6 18:40:06 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D09072D for ; Mon, 6 Oct 2014 18:40:06 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 41F69766 for ; Mon, 6 Oct 2014 18:40:04 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA21639 for ; Mon, 06 Oct 2014 21:39:57 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XbDCO-000Hxj-Q3 for freebsd-net@FreeBSD.org; Mon, 06 Oct 2014 21:39:56 +0300 Message-ID: <5432E1C4.6090209@FreeBSD.org> Date: Mon, 06 Oct 2014 21:39:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-net Subject: page fault in unp_gc -> unp_accessable Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 06 Oct 2014 18:40:06 -0000 First, I think that this panic could be related to a crash of chromium process that preceded it. Perhaps the crash triggered closing of sockets and that interacted badly with unp_gc code. Unread portion of the kernel message buffer: <6>pid 48502 (chrome), uid 1001: exited on signal 11 (core dumped) Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x100000021 fault code = supervisor read data, page not present ... (kgdb) bt #0 doadump (textdump=1) at pcpu.h:223 #1 0xffffffff8063d9fd in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:445 #2 0xffffffff8063df3f in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:621 #3 0xffffffff80861f4f in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:866 #4 0xffffffff8086229c in trap_pfault (frame=0xfffffe01dd5d89e0, usermode=) at /usr/src/sys/amd64/amd64/trap.c:677 #5 0xffffffff808618be in trap (frame=0xfffffe01dd5d89e0) at /usr/src/sys/amd64/amd64/trap.c:426 #6 0xffffffff808623f7 in trap_check (frame=) at /usr/src/sys/amd64/amd64/trap.c:620 #7 0xffffffff80845122 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #8 0xffffffff806d6668 in unp_gc (arg=0x10, pending=32) at /usr/src/sys/kern/uipc_usrreq.c:2152 #9 0xffffffff8068f465 in taskqueue_run_locked (queue=0xfffff80012294600) at /usr/src/sys/kern/subr_taskqueue.c:371 #10 0xffffffff80690258 in taskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_taskqueue.c:642 #11 0xffffffff80605a1a in fork_exit (callout=0xffffffff80690190 , arg=0xffffffff80ee17c0, frame=0xfffffe01dd5d8c00) at /usr/src/sys/kern/kern_fork.c:977 #12 0xffffffff8084565e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:605 (kgdb) fr 8 #8 0xffffffff806d6668 in unp_gc (arg=0x10, pending=32) at /usr/src/sys/kern/uipc_usrreq.c:2152 2152 fp = fdep[i]->fde_file; (kgdb) list 2147 struct unpcb *unp; 2148 struct file *fp; 2149 int i; 2150 2151 for (i = 0; i < fdcount; i++) { 2152 fp = fdep[i]->fde_file; 2153 if ((unp = fptounp(fp)) == NULL) 2154 continue; 2155 if (unp->unp_gcflag & UNPGC_REF) 2156 continue; (kgdb) disassemble ... 0xffffffff806d6660 : mov 0x10(%rdx,%rax,8),%rcx 0xffffffff806d6665 : mov (%rcx),%rcx 0xffffffff806d6668 : cmpw $0x2,0x20(%rcx) 0xffffffff806d666d : jne 0xffffffff806d66b0 0xffffffff806d666f : mov (%rcx),%rcx 0xffffffff806d6672 : test %rcx,%rcx 0xffffffff806d6675 : je 0xffffffff806d66b0 0xffffffff806d6677 : mov 0x20(%rcx),%rbx 0xffffffff806d667b : cmp %r14,0x8(%rbx) 0xffffffff806d667f : jne 0xffffffff806d66b0 0xffffffff806d6681 : mov 0x10(%rcx),%r9 0xffffffff806d6685 : test %r9,%r9 0xffffffff806d6688 : je 0xffffffff806d66b0 0xffffffff806d668a : movzwl 0x6a(%r9),%r10d 0xffffffff806d668f : test $0x1,%r10b 0xffffffff806d6693 : jne 0xffffffff806d66b0 0xffffffff806d6695 : and $0xfffc,%r10d 0xffffffff806d669c : or $0x1,%r10d 0xffffffff806d66a0 : mov %r10w,0x6a(%r9) 0xffffffff806d66a5 : incl 0xffffffff80e45604 0xffffffff806d66ac : nopl 0x0(%rax) 0xffffffff806d66b0 : inc %rax 0xffffffff806d66b3 : cmp %r15d,%eax 0xffffffff806d66b6 : jl 0xffffffff806d6660 ... (kgdb) i reg rax 0x1 1 rbx 0xfffff800358713c0 -8795194977344 rcx 0x100000001 4294967297 rdx 0xfffff8006d327420 -8794260999136 rsi 0x20 32 rdi 0x10 16 rbp 0xfffffe01dd5d8b20 0xfffffe01dd5d8b20 rsp 0xfffffe01dd5d8aa0 0xfffffe01dd5d8aa0 r8 0xfffff8006d327400 -8794260999168 r9 0xffffffff809c07de -2137258018 r10 0xfffff80012294630 -8795788327376 r11 0xfffff8006d327400 -8794260999168 r12 0xfffff801e7420000 -8787918192640 r13 0x1fffffff8 8589934584 r14 0xffffffff80c535a8 -2134559320 r15 0x2 2 rip 0xffffffff806d6668 0xffffffff806d6668 eflags 0x10297 66199 .... (kgdb) p (struct filedescent**)(0xfffff8006d327420 + 0x10) $8 = (struct filedescent **) 0xfffff8006d327430 (kgdb) p $8[0] $9 = (struct filedescent *) 0xfffff800499a9d00 (kgdb) p $8[1] $10 = (struct filedescent *) 0xfffff800499a9d30 (kgdb) p *$9 $11 = {fde_file = 0xfffff8016ccf7cf0, fde_caps = {fc_rights = {cr_rights = {0, 0}}, fc_ioctls = 0x1, fc_nioctls = 0, fc_fcntls = 0}, fde_flags = 0 '\0'} (kgdb) p *$10 $12 = {fde_file = 0x100000001, fde_caps = {fc_rights = {cr_rights = {0, 0}}, fc_ioctls = 0x0, fc_nioctls = 0, fc_fcntls = 0}, fde_flags = 0 '\0'} (kgdb) p $11.fde_file $13 = (struct file *) 0xfffff8016ccf7cf0 (kgdb) p *$11.fde_file $14 = {f_data = 0xfffff8002c001000, f_ops = 0xfffff801d391b588, f_cred = 0x17f0b, f_vnode = 0xffffffff809440d1, f_type = 0, f_vnread_flags = 625, f_flag = 0, f_count = 0, f_seqcount = 0, f_nextoff = 1, f_vnun = { fvn_cdevpriv = 0xffffffff809440dd, fvn_advice = 0xffffffff809440dd}, f_offset = 40960000, f_label = 0x0} (kgdb) p *$14.f_ops $15 = {fo_read = 0xffffffff8098daa8 , fo_write = 0xffffffff80bfab00 , fo_truncate = 0xfffff8016ccf7cf0, fo_ioctl = 0xfffff8001aeb1990, fo_poll = 0, fo_kqfilter = 0xfffff801d391bb30, fo_stat = 0, fo_close = 0, fo_chmod = 0, fo_chown = 0, fo_sendfile = 0, fo_seek = 0xfffff801d391b5d8, fo_flags = 0} (kgdb) p *$14.f_vnode $16 = {v_tag = 0x6f6c5f7a3e2d707a
, v_op = 0x3e2d707a26006b63, v_data = 0x746e657261705f7a, ...} So, it looks like elements of fdep[] point to some trashed data. Or the arrays itself does not hold good values. I am not familiar with the code, but it seems that unp_accessable() is invoked as a callback from unp_scan() which passes data from control a message packet reinterpreted as an array of struct filedescent pointers. This is r271950 11.0-CURRENT. I'd appreciate any suggestions. It's hard to extract data because of all the inlining but if anyone would like to see any additional data, then please let me know. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 04:04:37 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6D78B89 for ; Tue, 7 Oct 2014 04:04:37 +0000 (UTC) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 699CCA8A for ; Tue, 7 Oct 2014 04:04:36 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id s7so4428454qap.18 for ; Mon, 06 Oct 2014 21:04:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=LKRC469c7vv/IuRC5aXEmjQQ7Ag4hdBT57Gdv+oExNA=; b=HGqPGpLj5mA1g5YkznM2C15/T4B7C0mCLk+LuwpiaNKcbXbckub4qZt+D1z0n+IRFJ UbHXCY2eGoQ+PQNEOKq1bpOzSw/Fq0MYLG70gfgFtDM0aoEpR1LlInNYLSEIezVywyqi vw4rzfwDxKb8wlcxGkHeTe3JPNQ8kKhXCvI2/VvquEtg7O0Zpw5GcIDn42Kxd5BZHCu8 6XpQaa7JrmT3KVUP9zCnvzPdCSJnwANgGyjsEm0rc/GIMbmjUYqZC4Hj+bZrmd92tx4j Cy/UTqhBl1eK+Ys+eZWGIygQRTknwyoRZJ25sKfJ4t62pezcmS/bzOJtXI5m3h3cD7SW 7tOQ== X-Gm-Message-State: ALoCoQns9NmDIEjB9QhlaFNzm2i/klsx/SFHdT/4X5hQIMb5WPK1/XvV0mTK7KeXulVgLSJPZieF MIME-Version: 1.0 X-Received: by 10.140.102.9 with SMTP id v9mr32870360qge.38.1412654670712; Mon, 06 Oct 2014 21:04:30 -0700 (PDT) Received: by 10.96.26.227 with HTTP; Mon, 6 Oct 2014 21:04:30 -0700 (PDT) Date: Mon, 6 Oct 2014 23:04:30 -0500 Message-ID: Subject: Failed to run multi-thread using pkt-gen From: Yue Zhuo To: net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 04:04:37 -0000 Hi there, I was testing the newest netmap on a dual-port x520-T2 adapter using a 6-core machine. However, I always get error in* nm_txsync_prologue *for n - 1 threads when I try to use n threads (n > 1), which indicates the cur pointer points to a wrong place. At last, only one thread works correctly. Here is how I send packets: ./pkt-gen -i ix0 -f tx -c 6 -p 6 Any ideas about the issue? Thanks, Yue From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 11:22:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0A89748; Tue, 7 Oct 2014 11:22:07 +0000 (UTC) Received: from relaygateway02.edpnet.net (relaygateway02.edpnet.net [212.71.1.211]) by mx1.freebsd.org (Postfix) with ESMTP id 90178EE8; Tue, 7 Oct 2014 11:22:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAGjMM1TV25TV/2dsb2JhbABfgw5TWIMDyWAMh0sCgRAXAXuEAwEBAQMBAQIgBC8jEAsRAwECAQkTDgICDwUUERYOE4g2DAmsSo5YhjQBF49iEQE/EQcGgnGBVAWGK5AJgkGBSYMDAYEtg0SNGIN/giCBRTsvAYEOgTsBAQE X-IPAS-Result: AngGAGjMM1TV25TV/2dsb2JhbABfgw5TWIMDyWAMh0sCgRAXAXuEAwEBAQMBAQIgBC8jEAsRAwECAQkTDgICDwUUERYOE4g2DAmsSo5YhjQBF49iEQE/EQcGgnGBVAWGK5AJgkGBSYMDAYEtg0SNGIN/giCBRTsvAYEOgTsBAQE X-IronPort-AV: E=Sophos;i="5.04,669,1406584800"; d="scan'208";a="268820423" Received: from 213.219.148.213.adsl.dyn.edpnet.net (HELO mordor.lan) ([213.219.148.213]) by relaygateway02.edpnet.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2014 12:46:31 +0200 Date: Tue, 7 Oct 2014 13:21:47 +0200 From: Julien Cigar To: hiren panchasara Subject: Re: [jcigar@ulb.ac.be: Listen queue overflow: 8 already in queue awaiting acceptance] Message-ID: <20141007112147.GI63350@mordor.lan> References: <20141002164202.GI29361@mordor.lan> <20141002181958.GJ29361@mordor.lan> <20141003080150.GL29361@mordor.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VSaCG/zfRnOiPJtU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , FreeBSD Stable Mailing List X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 11:22:07 -0000 --VSaCG/zfRnOiPJtU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 03, 2014 at 10:31:56AM -0700, hiren panchasara wrote: > On Fri, Oct 3, 2014 at 1:01 AM, Julien Cigar wrote: > > On Thu, Oct 02, 2014 at 04:36:49PM -0700, hiren panchasara wrote: > >> On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote: > >> > On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote: > >> >> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wro= te: > >> >> > sorry for cross-posting, I'm forwarding this as it seems that par= t of > >> >> > the problem is also related to: > >> >> > https://lists.freebsd.org/pipermail/freebsd-net/2014-September/03= 9664.html > >> >> > >> >> Umm, this looks like a different problem than the subject of this e= mail. > >> > > >> > yes and no, seems the same hardware (HP and igb) and I have also some > >> > "requests for mbufs denied" (https://dpaste.de/t8kJ/raw) without any > >> > reasons. I should add that the box hanged a week ago and I had to do= a > >> > hard reboot, I have the feeling that it's somewhat related to this > >> > problem .. > >> > > >> I suggest you try to debug these 2 problems separately. Did you get a > >> chance to look at kgdb to find the culprit process as I suggested > >> below? > > > > I tried what you suggested, but I get a "No struct type named inpcb" > > Any idea ? :) >=20 > Is your kernel not build with debug symbols? Can you share your kernconf? indeed.. I always disable debug symbols on the production machines this is my kernconf: https://dpaste.de/8658/raw maybe I should give 10.1-RELEASE a try now that it's out soon .. >=20 > I have following in my kernconf: >=20 > makeoptions DEBUG=3D-g > options KDB > options KDB_TRACE > options DDB >=20 > cheers, > Hiren >=20 > >> > >> cheers, > >> Hiren > >> >> > > >> >> > I also wonder if something has been fixed in -STABLE in this area= .. > >> >> > > >> >> > (please keep me in CC as I'm not subscribed on freebsd-net@ an > >> >> > freebsd-stable@) > >> >> > > >> >> > -- > >> >> > Julien Cigar > >> >> > Belgian Biodiversity Platform (http://www.biodiversity.be) > >> >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23= C0 > >> >> > No trees were killed in the creation of this message. > >> >> > However, many electrons were terribly inconvenienced. > >> >> > > >> >> > > >> >> > ---------- Forwarded message ---------- > >> >> > From: Julien Cigar > >> >> > To: freebsd-questions@freebsd.org > >> >> > Cc: > >> >> > Date: Thu, 2 Oct 2014 11:52:06 +0200 > >> >> > Subject: Listen queue overflow: 8 already in queue awaiting accep= tance > >> >> > Hello, > >> >> > > >> >> > I'm running 10-RELEASE on a HP Proliant DL160 Gen8 and I'm seeing= the > >> >> > following in my kernel logs: > >> >> > sonewconn: pcb 0xfffff8010e561310: Listen queue overflow: 8 alrea= dy in > >> >> > queue awaiting acceptance > >> >> > >> >> This usually means the application is not keeping up with the incom= ing > >> >> connections. > >> >> > > >> >> > I already raised kern.ipc.soacceptqueue to 1024 and netstat -naA= | grep > >> >> > "fffff8010e561310" returns nothing > >> >> > >> >> This is the usual way of finding the culprit process. If this doesn= 't > >> >> return anything, it probably means that it is a short-lived process. > >> >> > >> >> Here is an example of what you could do: > >> >> > >> >> sonewconn: pcb 0xfffff8008f40cb10: Listen queue overflow: 1 already= in queue > >> >> awaiting acceptance > >> >> > >> >> From kgdb, > >> >> (kgdb) p ((struct inpcb *)0xfffff8008f40cb10)->inp_inc > >> >> $3 =3D {inc_flags =3D 0 '\0', inc_len =3D 0 '\0', inc_fibnum =3D 0,= inc_ie =3D {ie_fport > >> >> =3D 0, ie_lport =3D 10295, ie_dependfaddr =3D { > >> >> ie46_foreign =3D {ia46_pad32 =3D {0, 0, 0}, ia46_addr4 =3D {s= _addr =3D 0}}, > >> >> ie6_foreign =3D {__u6_addr =3D { > >> >> __u6_addr8 =3D '\0' , __u6_addr16 =3D {= 0, 0, 0, 0, 0, > >> >> 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}, > >> >> ie_dependladdr =3D {ie46_local =3D {ia46_pad32 =3D {0, 0, 0}, i= a46_addr4 =3D > >> >> {s_addr =3D 0}}, ie6_local =3D {__u6_addr =3D { > >> >> __u6_addr8 =3D '\0' , __u6_addr16 =3D {= 0, 0, 0, 0, 0, > >> >> 0, 0, 0}, __u6_addr32 =3D {0, 0, 0, 0}}}}}} > >> >> > >> >> Here, ie_lport =3D 10295 which is in n/w byte order and converting = it to host > >> >> byte order, 10295 -> 0x2837 and swapping them gives us 0x3728 which= is 14120. > >> >> > >> >> Now, use sockstat to find out what process is on that port: > >> >> > >> >> $ sockstat -l | grep 14120 > >> >> > >> >> cheers, > >> >> Hiren > >> > > >> > -- > >> > Julien Cigar > >> > Belgian Biodiversity Platform (http://www.biodiversity.be) > >> > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > >> > No trees were killed in the creation of this message. > >> > However, many electrons were terribly inconvenienced. > > > > -- > > Julien Cigar > > Belgian Biodiversity Platform (http://www.biodiversity.be) > > PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 > > No trees were killed in the creation of this message. > > However, many electrons were terribly inconvenienced. --=20 Julien Cigar Belgian Biodiversity Platform (http://www.biodiversity.be) PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0 No trees were killed in the creation of this message. However, many electrons were terribly inconvenienced. --VSaCG/zfRnOiPJtU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJUM8zLAAoJEAi2KiTKQR5pRKUQALrPkS3bp0m0eQsZW5x0kH8L B3Mvkenq2GlaK8F5WtrQCwMsjoTyDrI2AOZ959nal2zOKY+ZxlF9b0F+Umjz25Pc XkgdMJdCKcQ/LRicfz2EzYUzfygcYA4DB8OOc3O+12Oaz/J75s/AeFUoo54gjRb8 ylAlfGWkos+dr6xp/Sws6k+G2WYTYNehirdrx+RsKg+6wDvlOH47gMvqiIb8c3FR RvSZ3BxDRpLZRkkNMlPgs/fAXxuK80mwgTEW3DAomr50GyuN15Dnr9B6Hoybyvfr ngCs0gXVyaK06RLnGTS9jn9FAeOWPOd4ok6ChRZMPx/3FwRhpfK5zHcNGpowq3u1 zbYgRCuSAH+QTY+nfOW4O/jjaQ5goGOiOcSHtr0azHaMNW8KfHmXu/AeG+xqPP7y tYXj4Xx4nl5kmhyscROcRjng+cRA1EXWnuU+moUhgaDU2sBIv8o/JvjY642poNHu njjr37Ya7o7nFZ4iQ73PWgG20bQOlFp0Knk8hCkIWjohQVRiQIZ3tZw7VCOK3dI3 DuwdGI13Oe54tJIUG1iMlxgOC0ZyDK9EKJeIZ9T4odrRO+kYcQbOjMj3Mv3Qj5/8 O20+43aa27XgwHEOyycNRycA4Czf0so8UKMpFpmw9u3m5jQD5r7MC1xu67PLBmEc mBbrpxpTcPVabVnFh0WE =+Pub -----END PGP SIGNATURE----- --VSaCG/zfRnOiPJtU-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 14:38:55 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A165694 for ; Tue, 7 Oct 2014 14:38:55 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 511789F4 for ; Tue, 7 Oct 2014 14:38:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s97EctmC043453 for ; Tue, 7 Oct 2014 14:38:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 176167] [ipsec][lagg] using lagg and ipsec causes immediate panic Date: Tue, 07 Oct 2014 14:38:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 14:38:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176167 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved CC| |ae@FreeBSD.org Resolution|--- |Unable to Reproduce Assignee|freebsd-net@FreeBSD.org |ae@FreeBSD.org --- Comment #3 from Andrey V. Elsukov --- Submitter reported that unable reproduce the problem anymore. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 15:29:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03B5CE1D for ; Tue, 7 Oct 2014 15:29:35 +0000 (UTC) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA2876B for ; Tue, 7 Oct 2014 15:29:34 +0000 (UTC) Received: by mail-qg0-f45.google.com with SMTP id q107so1991677qgd.4 for ; Tue, 07 Oct 2014 08:29:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=wgWuK9wXSdsUReKr/EL1o6TGqTvhx0Z3Wob6pHcQ6JE=; b=klcTNBVq6G/wVDv6Vk/dEDLGMKwAJH9x6LXANbZJr4BLJ1pxTFB9PybS7pkcwPenhh gPJ8wNSsEPbRsn09aSz/2ioqgGUVAVsK6rxHgYhQAXu/CTAxG1hqjDKRqH+rYgn5cqeh jpBxKiHG2iVV+J7DrEbpdAU6QfMPsxaptmdo9aU+4wRp2k3VZ7xr42t8Eu3fehiifgv6 mOGC6oHPuy5cTZL/okaLvMlJtGZVsjAvdoZgnJ2s1TiO5GY63kxC34tmVcIU4a0sBQp5 CNsAxC03EL+PBYlcPbYRwFXGkJEVTEzbqV2878iXAZ2b1iTRfvSBtJ0sSWW5lqIPGR3U 88pg== X-Gm-Message-State: ALoCoQlzjZVHMSAPmZAe/af2hgTaQx9JIKzAMLWR8sMWYqOa9qFKMhsL+145exAxOs7aVPSBVN36 MIME-Version: 1.0 X-Received: by 10.224.172.198 with SMTP id m6mr5305789qaz.19.1412695767141; Tue, 07 Oct 2014 08:29:27 -0700 (PDT) Received: by 10.96.26.227 with HTTP; Tue, 7 Oct 2014 08:29:27 -0700 (PDT) Date: Tue, 7 Oct 2014 10:29:27 -0500 Message-ID: Subject: Netmap: Failed to run multi-thread using pkt-gen From: Yue Zhuo To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 15:29:35 -0000 Hi there, I was testing the newest netmap on a dual-port x520-T2 adapter using a 6-core machine. However, I always get error in* nm_txsync_prologue *for n - 1 threads when I try to use n threads (n > 1), which indicates the cur pointer points to a wrong place. At last, only one thread works correctly. Here is how I send packets: ./pkt-gen -i ix0 -f tx -c 6 -p 6 Any ideas about the issue? Thanks, Yue From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 15:41:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AF70158 for ; Tue, 7 Oct 2014 15:41:32 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 129C925E for ; Tue, 7 Oct 2014 15:41:31 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gi9so6681776lab.35 for ; Tue, 07 Oct 2014 08:41: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:message-id:subject :from:to:cc:content-type; bh=rEcqjp3YBUVSwnEZl9fAyBaazw+wU95cQCI92QwaiLw=; b=oAlkVqXdHxOkHCb6OvNr+ZBSYgjNy+kRGvjcZHqSkE500U3wu44xHUjUrylJeK+Gbn nLC7HKnvV2eF5yXi1vYuVnvOnIRvFC3kbP5CmrNQ2A0gZjb1f+sWULR694BjXoDq3QUl TMaZO9zQVIvwq8uYpBzsh8il3qvUc2gWNtSqhXYmLBdkQ7V/t+b9chooYnI1kH0lUe30 oruilDKB6W3cFCX2DXlI8UBz70dGEe7CcJ4RhD/+MAyXcZeRKo/MOkkQtndUTm36ZG7p wzw4kzM+LfkOVtUy3m3r+s9K4+TdRCaVUixM2Ncn+NDHx3QBA+NF1rhkv1GmcbbyG0k6 WQVQ== MIME-Version: 1.0 X-Received: by 10.152.23.199 with SMTP id o7mr5101676laf.26.1412696490050; Tue, 07 Oct 2014 08:41:30 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.1.50 with HTTP; Tue, 7 Oct 2014 08:41:30 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Oct 2014 17:41:30 +0200 X-Google-Sender-Auth: MjIvV_TbJ-i1V_t3SIRIxbrZfe0 Message-ID: Subject: Re: Netmap: Failed to run multi-thread using pkt-gen From: Luigi Rizzo To: Yue Zhuo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 15:41:32 -0000 how many queues do you have ? you need to run with as many threads as there are queues. If hyperthreading is on you are likely to have 12 virtual cores, and depending on the OS the driver might limit the number to 8 (this is what happens on FreeBSD). pkt-gen with a single thread should tell you how many queues are available cheers luigi On Tue, Oct 7, 2014 at 5:29 PM, Yue Zhuo wrote: > Hi there, > > I was testing the newest netmap on a dual-port x520-T2 adapter using a > 6-core machine. > > However, I always get error in* nm_txsync_prologue *for n - 1 threads when > I try to use n threads (n > 1), which indicates the cur pointer points to a > wrong place. At last, only one thread works correctly. > > Here is how I send packets: ./pkt-gen -i ix0 -f tx -c 6 -p 6 > > Any ideas about the issue? > > > Thanks, > > Yue > _______________________________________________ > 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" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 15:52:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C4BFE27 for ; Tue, 7 Oct 2014 15:52:39 +0000 (UTC) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39F193CA for ; Tue, 7 Oct 2014 15:52:38 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id x3so5873711qcv.25 for ; Tue, 07 Oct 2014 08:52:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GOKPbDlyzsFH6rHYSq+rBpGtqC03XdVWoFYRhowOswA=; b=L16YbnmFGXlsJaSF7yUZrq0E5i0rjtzoz5zG9rYc6Oo2XfKu2pFqLBs0ql8YLPLKLe ZbpnfPhfElcEObER8h8AG+VR9vDi/3Oi4dZd/hQwfOKWg9Q/RE3vWnHWdIZh2jAfPXw3 KPriHZ6Yq7C4c7SQYNMRLelpqpBNl7ZekARSAfX166WSMO7rp8CjYVLZP+3p7d5eLvsp HsMa9Q8/WF+6niqvpGwFAVnYySDGxG5vwuCE1AAsiqPHcw+/sQmCA1nHav/nAWqdHDgW 4ZGjkWnn1NfTvV7Kry/PQoMJ+KItan9Y/Jb/Y2P1wht5pPUsermOU3asxKg6YF/c3SpH 3H1Q== X-Gm-Message-State: ALoCoQnvrEeKbSXGQw+aGZI9CyG0eV/0Oe/uNvqEYI/5W22Tyb8SUZmrdo42zxMdLFR2aQjRxA15 MIME-Version: 1.0 X-Received: by 10.140.88.47 with SMTP id s44mr7813403qgd.67.1412697152479; Tue, 07 Oct 2014 08:52:32 -0700 (PDT) Received: by 10.96.26.227 with HTTP; Tue, 7 Oct 2014 08:52:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Oct 2014 10:52:32 -0500 Message-ID: Subject: Re: Netmap: Failed to run multi-thread using pkt-gen From: Yue Zhuo To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 15:52:39 -0000 pkt-gen tells I have 6 queues. Yue On Tue, Oct 7, 2014 at 10:41 AM, Luigi Rizzo wrote: > how many queues do you have ? > you need to run with as many threads as there are queues. > If hyperthreading is on you are likely to have 12 virtual cores, > and depending on the OS the driver might limit the number to 8 > (this is what happens on FreeBSD). > > pkt-gen with a single thread should tell you how many queues > are available > > cheers > luigi > > > On Tue, Oct 7, 2014 at 5:29 PM, Yue Zhuo wrote: > >> Hi there, >> >> I was testing the newest netmap on a dual-port x520-T2 adapter using a >> 6-core machine. >> >> However, I always get error in* nm_txsync_prologue *for n - 1 threads when >> I try to use n threads (n > 1), which indicates the cur pointer points to >> a >> wrong place. At last, only one thread works correctly. >> >> Here is how I send packets: ./pkt-gen -i ix0 -f tx -c 6 -p 6 >> >> Any ideas about the issue? >> >> >> Thanks, >> >> Yue >> _______________________________________________ >> 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" >> > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 17:33:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AE8CCC4 for ; Tue, 7 Oct 2014 17:33:24 +0000 (UTC) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 371652BA for ; Tue, 7 Oct 2014 17:33:24 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id a141so5468762oig.15 for ; Tue, 07 Oct 2014 10:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=BHoMkNumYVr62B+6yLewe0nFe+XB3yraA4monk2p0kE=; b=fMfd8ROTuekGPHiJ7WqFY6xtJGJ6JcmXxu5RF6Fz8s315o5i/Je7m2wC48/4gF2ybg w4ngGAlgFO7BReRmnCEHPiAYXpxl85JjncNEUXOV/KropAMydiucUosqJfO5vRr0QuQH dpNldtgvd0jrUphVZ+87dpJLoRR+ysBEdr6y75BUuIW64+43MKmBi+FvaJE3vJjYvBDA AbwsqLXFOoIaLFqUWBRwYb6anQf122IJewcjTbwONYs8hIbREu1S3mxXoh2i5BEm5uK0 qwuMDp09w6YxruFQu4zUqxKOn9AeTpDIuxR4UFGiB8KPGiRCGX2L4ffrcxqtL+YpCADF +IlA== X-Received: by 10.60.37.196 with SMTP id a4mr6047829oek.45.1412703203538; Tue, 07 Oct 2014 10:33:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.93.40 with HTTP; Tue, 7 Oct 2014 10:33:03 -0700 (PDT) From: Raimundo Santos Date: Tue, 7 Oct 2014 14:33:03 -0300 Message-ID: Subject: ipfw and pf together are reliable? To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 17:33:24 -0000 Hello list! I have a need to use FWD in ipfw, but for my needs pf are much way simpler. I have tested some rules in the past year inside pf, even disabling states, but things do better with ipfw regarding FWD - do not know way. I have heard that ipfw and pf could work together, but with a lot of pain. I think that, if that works well, I can use only FWD in ipfw and the rest in pf. Is there a way and a reliable one to do that in 9.2 and 9.3? Thank you in advance, Raimundo Santos From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 23:41:58 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF23D4E1 for ; Tue, 7 Oct 2014 23:41:58 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97666253 for ; Tue, 7 Oct 2014 23:41:58 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s97Nfwob066290 for ; Tue, 7 Oct 2014 23:41:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194234] New: [ixgbe] Update ixgbe to 2.5.27 Date: Tue, 07 Oct 2014 23:41:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 23:41:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 Bug ID: 194234 Summary: [ixgbe] Update ixgbe to 2.5.27 Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: Normal Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: ricera10@gmail.com CC: freebsd-net@FreeBSD.org Created attachment 148084 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148084&action=edit Core code patch Core changes: - Fix to IXGBE_LEGACY_TX so it builds properly - Added commented-out options to Makefile for IXGBE_LEGACY_BUILD support, for builds on FreeBSD 7/8. This hasn't been tested thoroughly, though. - Wrap some counter(9) code in driver in __FreeBSD_version >= 1100036 defines so that there is still stats support in older versions of FreeBSD - Most of this is derived from r272227 for ixl/v(4) - Move SIOCGI2C ioctl under __FreeBSD_version >= 1100036 define as well - Two new device IDs Shared code changes: - Primarily changes to support upcoming 10 gig products and bug fixes. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Tue Oct 7 23:42:29 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 000E05C4 for ; Tue, 7 Oct 2014 23:42:28 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC760269 for ; Tue, 7 Oct 2014 23:42:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s97NgSWd067515 for ; Tue, 7 Oct 2014 23:42:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194234] [ixgbe] Update ixgbe to 2.5.27 Date: Tue, 07 Oct 2014 23:42:28 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ricera10@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 07 Oct 2014 23:42:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 Eric Joyner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ricera10@gmail.com --- Comment #1 from Eric Joyner --- Created attachment 148085 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148085&action=edit Shared code patch Attaching second patch -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-net@FreeBSD.ORG Wed Oct 8 00:34:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAB5DEB7; Wed, 8 Oct 2014 00:34:32 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B07A1965; Wed, 8 Oct 2014 00:34:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=oKGaD4bnX6AWf2IeWTMIIbtUu9CmWuPHCo2V532FS0w=; b=WeGbWp08JcbGTZfEN5bnN5dgcM/FQkLz3dsT4rzLTgg61SHy4126RIPo5q4gLQREiDMV0gizgssAGIzalWntuJKt/RdXxihK2CYmVKAXM6B1o54jdNCl/Suz0PlaZoF1ZzfUyejnl0wBWJuP57tVXIEIYX0te14Y+/0PmEuB/FU=; Received: from [182.9.144.112] (port=47866 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XbfD4-003JJO-K1; Tue, 07 Oct 2014 18:34:31 -0600 Date: Wed, 8 Oct 2014 08:34:24 +0800 From: Erich Dollansky To: Scot Hetzel Subject: Re: FreeBSD 10.1-RC1 Now Available --- lagg disables network inside jails Message-ID: <20141008083424.354b9d7c@X220.alogt.com> In-Reply-To: References: <20141005013247.GH1171@hub.FreeBSD.org> <20141005203401.440afc31@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: Glen Barber , freebsd-jail@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Stable , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 08 Oct 2014 00:34:33 -0000 Hi, jails work now with lagg0 again on my machine. It seems to me that it was a specific problem of this one machine. I installed the following revisions: 272555 starting point which failed 272400 failed 272000 works 272200 works 272300 works 272400 test again and it works 272400 installing world inside the jail and it works I then went to 272672 and it also works. It might was the sequence, it might was a configuration error on my side, all I know is that it works again. I also cross-compiled a kernel for the Raspberry which also works when using the latest firmware as YAMAMOTO Shigeru suggested. Erich On Sun, 5 Oct 2014 11:38:47 -0500 Scot Hetzel wrote: > On Sun, Oct 5, 2014 at 7:34 AM, Erich Dollansky > wrote: > > Hi, > > > > On Sat, 4 Oct 2014 21:32:47 -0400 > > Glen Barber wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> The first RC build of the 10.1-RELEASE release cycle is now > >> available > > > > I installed this shortly after your e-mail came. The result was the > > same as with BETA3. If you remember, I have had the problem that the > > network inside jails stopped working after I installed BETA3. The > > upgrade to RC1 did not change anything. > > > > I took now the time to investigate a bit. The result is simple. All > > works as expected until lagg becomes enabled. > > > > If I remember right, BETA1 was my last working version. > > > > I have an em and an iwn interface in the machine. I can use both of > > them without any problems. > > > > As I can reproduce this problem 100%, it might be a good idea if I > > help you to find the source of the problem. My problem would be: > > how. > > > > If somebody could tell me where to start looking for the error, we > > might find it soon. > > > You'll need to identify where in the src caused the issue for you. To > do this, you will need to identify where it was working (BETA1?). > You would then have to step thru the sources until you find the point > where it breaks. > > The easiest way would be to take the svn revision that is half way > between BETA1 and BETA3, compile and install it and see if it works. > You keep halving the result until you identify the commit that broke > it. > > Once the offending commit is identified, email the list. > From owner-freebsd-net@FreeBSD.ORG Wed Oct 8 11:37:00 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4069542 for ; Wed, 8 Oct 2014 11:37:00 +0000 (UTC) Received: from smtp-out.sentor.se (smtp-out.sentor.se [176.124.225.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A3E3160 for ; Wed, 8 Oct 2014 11:37:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by farmermaggot.shire.sentor.se (Postfix) with ESMTP id CD52AB61D497; Wed, 8 Oct 2014 13:30:46 +0200 (CEST) Date: Wed, 8 Oct 2014 13:30:46 +0200 (CEST) From: elof2@sentor.se To: freebsd-net Subject: Unable to kill a non-zombie process with -9 Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: snort-devel mailinglist X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 08 Oct 2014 11:37:00 -0000 I guess this is a bug report for FreeBSD 10.0. Sometimes I can't kill my snort process on FreeBSD 10.0. It won't die, even with kill -9. I'm not talking about a zombie process. Snort is a process that should die normally. I've run snort on over 100 nodes since FreeBSD v6.x and I've never seen this behavior until now in FreeBSD 10.0. Example: #ps faxuw USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 49222 53.4 2.2 492648 183012 - Rs 11:46AM 7:05.59 /usr/local/bin/snort -q -D -c snort.conf root 47937 0.0 2.2 488552 182864 - Ts 10:56AM 29:35.98 /usr/local/bin/snort -q -D -c snort.conf The pid 47937 has been killed (repeatedly) with -9. Its status is "Ts" meaning it is Stopped. But it won't actually die and disappear. The only way to get rid of it seem to be to reboot the machine. :-( (pid 49222 is the new process that was started after 47937 was killed) The problem doesn't happen all the time and I haven't found any patterns as to when it does. :-( If I restart snort once every day, it fails to die approximately 2-4 times per month. Even though the problem doesn't happen on every kill, it is a definately a recurring event. I began to see it on a heavily loaded 10GE sensor, so I thought it could have something to do with the ix driver, or the heavy load. But now another FreeBSD 10.0-sensor had the exact same problem, and this sensor don't have any 10GE NICs. In fact, this sensor has been running just fine with both FreeBSD 9.1 and 9.3 for the past years. Snort has always terminated correctly! After I reinstalled this machine with FreeBSD 10.0 last friday, snort has then terminated correctly every day until today, when it failed with the above pid 47937. (this sensor use the 'em' driver, not 'ixgbe') I'm running snort with the same configuration, settings, version, daq, libs, etc on 10.0 as I do on 9.3. None of the 9.3 sensors have this problem, so it has to be something new in FreeBSD 10.0. Q1: Has anyone seen anything simillar, or have any clues as to what is going on and why? Q2: Is there any other way to kill and purge the stopped process? I don't want it laying around. ('kill -HUP 1' didn't help) ( The closest thing I've come across myself is last year, when I tested enabling zerocopy-bpf in FreeBSD 9.1. Then I couldn't kill snort if the sniffer-interface was completely silent. The above problem is not like this though. I haven't enabled zerocopy and there are lots of mirrored traffic on the sniffer interface. ) /Elof From owner-freebsd-net@FreeBSD.ORG Wed Oct 8 16:14:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5711F30 for ; Wed, 8 Oct 2014 16:14:11 +0000 (UTC) Received: from fallback4.mail.ru (fallback4.mail.ru [94.100.181.169]) by mx1.freebsd.org (Postfix) with ESMTP id 91B2169D for ; Wed, 8 Oct 2014 16:14:11 +0000 (UTC) Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) by fallback4.mail.ru (mPOP.Fallback_MX) with ESMTP id 622F72C4CFC for ; Wed, 8 Oct 2014 20:10:49 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:To:Message-ID:From:Date; bh=KNA32MC4vQHBiNRRGbsVqFko2KH8FZ1NmqY4xpi0J0M=; b=cj2siGU1QoBVrbEl+Qbf8inlVtnTReEJBJ2Dy+zJZIHfo9o2m/HuiyrhRa1Do3j0VuLiZ+/A4iLC3uKAuWaDSwv8LHyS5zKC194E8NlrWuYghnD54FZk4jVJFMYcg85dTVoCDKcnlrmIl/vNVNY19mY7WW42uGmM+lTWp8kntvE=; Received: from [217.66.152.16] (port=4243 helo=[192.168.193.36]) by smtp33.i.mail.ru with esmtpa (envelope-from ) id 1Xbtp2-0004sR-FU for freebsd-net@freebsd.org; Wed, 08 Oct 2014 20:10:40 +0400 Date: Wed, 8 Oct 2014 20:10:37 +0400 From: Anthony Pankov X-Priority: 3 (Normal) Message-ID: <1051213945.20141008201037@mail.ru> To: freebsd-net@freebsd.org Subject: interface fib not inherited by bind()? MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Mras: Ok X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 08 Oct 2014 16:14:12 -0000 Greetings. I have a machine with interface IP1 connected to Provider1. Some time ago i've connected Provider2 to another interface IP2. I set new fib =B91 with provider2 setting and configure interface2 for fib 1 ('ifconfig if2 inet IP1 netmask mask2 fib 1'). Now i can do 'setfib 1 ping google.com' successfully. But when i run 'ping -S IP2 google.com' (using interface 2 as source) no outgoing packet found in Interface2. Does this mean that binding to interface IP do not inherit interface FIB for connection? Is this a bug or design? --=20 Best regards, Anthony mailto:ap00@mail.ru From owner-freebsd-net@FreeBSD.ORG Wed Oct 8 17:56:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1C3669E; Wed, 8 Oct 2014 17:56:57 +0000 (UTC) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 534812B6; Wed, 8 Oct 2014 17:56:57 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id a141so8482066oig.29 for ; Wed, 08 Oct 2014 10:56:56 -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=dJo0eP/xdn+4fSu9l6b8OthGg0xSus03yXgCMvltTlY=; b=Pv9GQgEhrkLRZCNFsg66YuZAYL758Av4AvTlhvPzpu4VAr7DHWOQtjjd7KXnC1BfuO zUi0vKIozFXqME2jTXE0+EZdeE0tVZBEz+1cU6ASx2CCeD8k/6ZNLgq/990oypwfSJX8 ZdACYKWwoYUF9yU1pHo4BuUj8XXOJQy9Plj0fJra8goCggJbUgjezBI+g1CtJf5g5oMV myVJGLX/rHhVZDVkNjQgRuy0kFXAzqN6cRg9bLt66Zv3PZbx0NXgtoJyA1CG0EB4EKRl uoVQG9mIiwmVVoR5rwzlzGGyMbIwZQCjpkg8147ckJuSlJc/wDpXjITs0Pt5467H3PU2 hbSw== MIME-Version: 1.0 X-Received: by 10.182.38.138 with SMTP id g10mr14621306obk.21.1412791016668; Wed, 08 Oct 2014 10:56:56 -0700 (PDT) Received: by 10.202.200.196 with HTTP; Wed, 8 Oct 2014 10:56:56 -0700 (PDT) In-Reply-To: <201410071428.15753.jhb@freebsd.org> References: <1410203348.1343.1.camel@bruno> <201410071146.26274.jhb@freebsd.org> <201410071428.15753.jhb@freebsd.org> Date: Wed, 8 Oct 2014 10:56:56 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Sean Bruno , davide@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 08 Oct 2014 17:56:57 -0000 On Tue, Oct 7, 2014 at 11:28 AM, John Baldwin wrote: > On Tuesday, October 07, 2014 2:06:42 pm Jason Wolfe wrote: > > Hey John, > > > > Happy to do this, but the pool of boxes is about 500 large, which is the > > reason I'm able to see a crash every day or so. I've pulled a portion of > > them out of service to switch them over to a a kernel with WITNESS > options, > > might that assist in the same manner if we catch a crash there? If > you're > > thinking the KTR traces are required to diagnose this I'll get started on > > that though. I've also cut 10.1-RC1 with some ixgbe fixes for future > use, > > but noticed kern_timeout.c has been static for the past 8 months. Thanks > > again for your help. > > I don't think WITNESS will really help in this case. ixgbe just happens to > be trying to schedule a timer and running into a problem that the timer is > spinning on another CPU. While the kern_timeout code hasn't changed in a > while, it may be an edge case provoked by another bug elsewhere. It's also > possible I suppose that a lot of callouts are scheduled for some reason. > > Hmm, maybe we can still figure this out from your dumps. We can still get > to > '*cc' via an alternate route. First, IIRC, the thread is an idle thread, > so its name should indicate which CPU it is for: > > % sudo procstat -at | grep 100003 > 11 100003 idle idle: cpu0 0 255 run - > > (Hmm, I bet that is always CPU 0). That means we can find 'cc' by doing > 'p cc_cpu[0]' in kgdb. Can you do that from the last core dump along with > 'p last' in frame 4? > > Grrr. Looks like cc->cc_lastscan is already overwritten by the time you've > crashed, so we can't work back to the original value of 'firstb'. > > However, there is a sysctl you can invoke to get callout stats. Maybe run > 'sysctl kern.callout_stats=1' on one of your existing servers and then > check > dmesg. On an idle machine sitting here running stable/10 I have 86 callout > scheduled currently: > > Scheduled callouts statistic snapshot: > Callouts: 86 Buckets: 32768*8 Bucket size: 0.003906s > C/Bk: med 0 avg 0.000328 max 19 > Time: med 2.000000s avg 719.566333s max 19807.162515s > Prec: med 0.500000s avg 60.250613s max 1799.999875s > Distribution: buckets time tcum prec pcum > 0.000000s 2**-12 0 0 1 1 > 0.007812s 2**1 1 1 1 2 > 0.015625s 2**2 0 1 2 4 > 0.031250s 2**3 5 6 4 8 > 0.062500s 2**4 0 6 20 28 > 0.125000s 2**5 1 7 1 29 > 0.250000s 2**6 4 11 11 40 > 0.500000s 2**7 7 18 14 54 > 1.000000s 2**8 23 41 11 65 > 2.000000s 2**9 2 43 3 68 > 4.000000s 2**10 13 56 4 72 > 8.000000s 2**11 2 58 0 72 > 16.000000s 2**12 11 69 2 74 > 32.000000s 2**13 1 70 1 75 > 64.000000s 2**14 3 73 0 75 > 128.000000s 2**15 1 74 3 78 > 256.000000s 2**16 4 78 1 79 > 512.000000s 2**17 0 78 6 85 > 2048.000000s 2**19 2 80 1 86 > 8192.000000s 2**21 5 85 0 86 > 16384.000000s 2**22 1 86 0 86 > > It would be interesting to see if you have a much higher number. > > -- > John Baldwin > I was trying to keep the chatter off the list, but John has been insanely helpful here. Looping the list back in as his insight into debugging this is likely relevant to others. John, Correct 100003 is always CPU0, on our end at least. Jackpot on the cc_cpu[0] also, here are cores across 3 different 'spin lock callout held by tid 100003 too long' machines. Callouts on an idle machine are in line with yours at 90, and a somewhat idle box pushing ~500Mb/s has in the 3000-4000 range. (kgdb) tid 100003 [Switching to thread 40 (Thread 100003)]#0 0xffffffff80ac39b8 in cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 1432 savectx(&stoppcbs[cpu]); (kgdb) up 4 #4 0xffffffff80733f79 in callout_process (now=3549882673091690) at /usr/src/sys/kern/kern_timeout.c:443 443 tmp = LIST_FIRST(sc); (kgdb) list 438 } 439 440 /* Iterate callwheel from firstb to nowb and then up to lastb. */ 441 do { 442 sc = &cc->cc_callwheel[firstb & callwheelmask]; 443 tmp = LIST_FIRST(sc); 444 while (tmp != NULL) { 445 /* Run the callout if present time within allowed. */ 446 if (tmp->c_time <= now) { 447 /* (kgdb) p cc_cpu[0] $1 = {cc_lock = {lock_object = {lo_name = 0xffffffff80ccbec7 "callout", lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, cc_exec_entity = {{cc_next = 0x0, cc_curr = 0x0, ce_migration_func = 0, ce_migration_arg = 0x0, ce_migration_cpu = 64, ce_migration_time = 0, ce_migration_prec = 0, cc_cancel = false, cc_waiting = false}, { cc_next = 0xffffffff812a7af0, cc_curr = 0x0, ce_migration_func = 0, ce_migration_arg = 0x0, ce_migration_cpu = 64, ce_migration_time = 0, ce_migration_prec = 0, cc_cancel = false, cc_waiting = false}}, cc_callout = 0xfffffe000069f000, cc_callwheel = 0xfffffe00007c1000, cc_expireq = {tqh_first = 0x0, tqh_last = 0xffffffff812a0510}, cc_callfree = {slh_first = 0xfffffe00007c02c0}, cc_firstevent = 3549882673088716, cc_lastscan = 3549882673091690, cc_cookie = 0xfffff800151f4b80, cc_bucket = 6515} (kgdb) p last $2 = 3549882929381376 (kgdb) tid 100003 [Switching to thread 40 (Thread 100003)]#0 0xffffffff80ac39b8 in cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 1432 savectx(&stoppcbs[cpu]); (kgdb) up 4 #4 0xffffffff80733fab in callout_process (now=6792755852650669) at /usr/src/sys/kern/kern_timeout.c:467 467 LIST_REMOVE(tmp, c_links.le); (kgdb) list 462 #endif 463 1); 464 tmp = cc->cc_exec_next_dir; 465 } else { 466 tmpn = LIST_NEXT(tmp, c_links.le); 467 LIST_REMOVE(tmp, c_links.le); 468 TAILQ_INSERT_TAIL(&cc->cc_expireq, 469 tmp, c_links.tqe); 470 tmp->c_flags |= CALLOUT_PROCESSED; 471 tmp = tmpn; (kgdb) p cc_cpu[0] $1 = {cc_lock = {lock_object = {lo_name = 0xffffffff80ccbec7 "callout", lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, cc_exec_entity = {{cc_next = 0x0, cc_curr = 0x0, ce_migration_func = 0, ce_migration_arg = 0x0, ce_migration_cpu = 64, ce_migration_time = 0, ce_migration_prec = 0, cc_cancel = true, cc_waiting = false}, { cc_next = 0x0, cc_curr = 0x0, ce_migration_func = 0, ce_migration_arg = 0x0, ce_migration_cpu = 64, ce_migration_time = 0, ce_migration_prec = 0, cc_cancel = false, cc_waiting = false}}, cc_callout = 0xfffffe000069f000, cc_callwheel = 0xfffffe00007c1000, cc_expireq = {tqh_first = 0xfffffe0003f461b0, tqh_last = 0xffffffff81257138}, cc_callfree = {slh_first = 0xfffffe00007c02c0}, cc_firstevent = 6792755922031366, cc_lastscan = 6792755852650669, cc_cookie = 0xfffff800151f4b80, cc_bucket = 31145} (kgdb) p last $2 = 6792757989343232 (kgdb) tid 100003 [Switching to thread 40 (Thread 100003)]#0 0xffffffff80ac39b8 in cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 1432 savectx(&stoppcbs[cpu]); (kgdb) up 4 #4 0xffffffff8073406e in callout_process (now=4354614125734311) at /usr/src/sys/kern/kern_timeout.c:487 487 if (tmp->c_time < first) (kgdb) list 482 if (tmp->c_time > last) { 483 lastb = nowb; 484 goto next; 485 } 486 /* Update first and last time, respecting this event. */ 487 if (tmp->c_time < first) 488 first = tmp->c_time; 489 tmp_max = tmp->c_time + tmp->c_precision; 490 if (tmp_max < last) 491 last = tmp_max; (kgdb) p cc_cpu[0] $1 = {cc_lock = {lock_object = {lo_name = 0xffffffff80ccbec7 "callout", lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, cc_exec_entity = {{cc_next = 0x0, cc_curr = 0x0, ce_migration_func = 0, ce_migration_arg = 0x0, ce_migration_cpu = 64, ce_migration_time = 0, ce_migration_prec = 0, cc_cancel = false, cc_waiting = false}, { cc_next = 0x0, cc_curr = 0x0, ce_migration_func = 0, ce_migration_arg = 0x0, ce_migration_cpu = 64, ce_migration_time = 0, ce_migration_prec = 0, cc_cancel = false, cc_waiting = false}}, cc_callout = 0xfffffe000069f000, cc_callwheel = 0xfffffe00007c1000, cc_expireq = {tqh_first = 0x0, tqh_last = 0xffffffff812a0510}, cc_callfree = {slh_first = 0xfffffe00007c02c0}, cc_firstevent = 4354614125730601, cc_lastscan = 4354614125734311, cc_cookie = 0xfffff800151f4b80, cc_bucket = 32667} (kgdb) p last $2 = 4354614660956160 Scheduled callouts statistic snapshot: Callouts: 90 Buckets: 32768*6 Bucket size: 0.003906s C/Bk: med 0 avg 0.000457 max 13 Time: med 4.000000s avg 1231.642745s max 56836.522122s Prec: med 1.000000s avg 194.507344s max 5399.999627s Distribution: buckets time tcum prec pcum 0.000000s 2**-12 0 0 1 1 0.000030s 2**-7 1 1 0 1 0.015625s 2**2 0 1 2 3 0.031250s 2**3 1 2 17 20 0.062500s 2**4 1 3 14 34 0.125000s 2**5 15 18 1 35 0.250000s 2**6 6 24 1 36 0.500000s 2**7 12 36 5 41 1.000000s 2**8 3 39 15 56 4.000000s 2**10 17 56 9 65 8.000000s 2**11 2 58 0 65 16.000000s 2**12 0 58 12 77 32.000000s 2**13 2 60 1 78 64.000000s 2**14 6 66 4 82 128.000000s 2**15 17 83 3 85 256.000000s 2**16 0 83 2 87 1024.000000s 2**18 4 87 0 87 4096.000000s 2**20 0 87 3 90 32768.000000s 2**23 2 89 0 90 65536.000000s 2**24 1 90 0 90 Scheduled callouts statistic snapshot: Callouts: 3613 Buckets: 32768*6 Bucket size: 0.003906s C/Bk: med 0 avg 0.018376 max 22 Time: med 64.000000s avg 167.175352s max 86397.094792s Prec: med 4.000000s avg 13.837570s max 5399.999627s Distribution: buckets time tcum prec pcum 0.000000s 2**-12 0 0 1 1 0.001953s 2**-1 0 0 2 3 0.003906s 2**0 2 2 0 3 0.007812s 2**1 2 4 0 3 0.015625s 2**2 3 7 48 51 0.031250s 2**3 5 12 79 130 0.062500s 2**4 9 21 139 269 0.125000s 2**5 24 45 27 296 0.250000s 2**6 74 119 120 416 0.500000s 2**7 117 236 30 446 1.000000s 2**8 89 325 202 648 2.000000s 2**9 76 401 24 672 4.000000s 2**10 156 557 2862 3534 8.000000s 2**11 187 744 1 3535 16.000000s 2**12 370 1114 12 3547 32.000000s 2**13 589 1703 1 3548 64.000000s 2**14 1876 3579 55 3603 128.000000s 2**15 18 3597 2 3605 256.000000s 2**16 1 3598 2 3607 512.000000s 2**17 1 3599 0 3607 1024.000000s 2**18 6 3605 0 3607 2048.000000s 2**19 2 3607 0 3607 4096.000000s 2**20 0 3607 6 3613 32768.000000s 2**23 1 3608 0 3613 65536.000000s 2**24 5 3613 0 3613 Jason From owner-freebsd-net@FreeBSD.ORG Wed Oct 8 19:30:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF3C6143; Wed, 8 Oct 2014 19:30:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81734E75; Wed, 8 Oct 2014 19:30:51 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 99CA2B976; Wed, 8 Oct 2014 15:30:49 -0400 (EDT) From: John Baldwin To: Jason Wolfe Subject: Re: ixgbe(4) spin lock held too long Date: Wed, 08 Oct 2014 15:29:32 -0400 Message-ID: <2077446.sYcZo9xEXb@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <1410203348.1343.1.camel@bruno> <201410071428.15753.jhb@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 08 Oct 2014 15:30:49 -0400 (EDT) Cc: Sean Bruno , freebsd-net@freebsd.org, Eric van Gyzen , davide@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 08 Oct 2014 19:30:51 -0000 On Wednesday, October 08, 2014 10:56:56 AM Jason Wolfe wrote: > On Tue, Oct 7, 2014 at 11:28 AM, John Baldwin wrote: > > On Tuesday, October 07, 2014 2:06:42 pm Jason Wolfe wrote: > > > Hey John, > > > > > > Happy to do this, but the pool of boxes is about 500 large, which is the > > > reason I'm able to see a crash every day or so. I've pulled a portion > > > of them out of service to switch them over to a a kernel with WITNESS options, > > > might that assist in the same manner if we catch a crash there? If you're > > > thinking the KTR traces are required to diagnose this I'll get started on > > > that though. I've also cut 10.1-RC1 with some ixgbe fixes for future use, > > > but noticed kern_timeout.c has been static for the past 8 months. > > > Thanks again for your help. > > > > I don't think WITNESS will really help in this case. ixgbe just happens to > > be trying to schedule a timer and running into a problem that the timer is > > spinning on another CPU. While the kern_timeout code hasn't changed in a > > while, it may be an edge case provoked by another bug elsewhere. It's also > > possible I suppose that a lot of callouts are scheduled for some reason. > > > > Hmm, maybe we can still figure this out from your dumps. We can still get to > > '*cc' via an alternate route. First, IIRC, the thread is an idle thread, > > so its name should indicate which CPU it is for: > > > > % sudo procstat -at | grep 100003 > > > > 11 100003 idle idle: cpu0 0 255 run - > > > > (Hmm, I bet that is always CPU 0). That means we can find 'cc' by doing > > 'p cc_cpu[0]' in kgdb. Can you do that from the last core dump along with > > 'p last' in frame 4? > > > > Grrr. Looks like cc->cc_lastscan is already overwritten by the time you've > > crashed, so we can't work back to the original value of 'firstb'. > > > > However, there is a sysctl you can invoke to get callout stats. Maybe run > > 'sysctl kern.callout_stats=1' on one of your existing servers and then > > check dmesg. On an idle machine sitting here running stable/10 I have 86 > > callout scheduled currently: > > Correct 100003 is always CPU0, on our end at least. Jackpot on the > cc_cpu[0] also, here are cores across 3 different 'spin lock callout held > by tid 100003 too long' machines. Callouts on an idle machine are in line > with yours at 90, and a somewhat idle box pushing ~500Mb/s has in the > 3000-4000 range. Unfortunately, the thing I wanted out of cc_cpu[0] is the previous value of cc_lastscan so I could work back to what 'firstb' is and see if it sticks in the loop forever for some reason. However, cc_lastscan is overwritten by the time this cores. Still, we can still tell something perhaps: > (kgdb) tid 100003 > [Switching to thread 40 (Thread 100003)]#0 0xffffffff80ac39b8 in > cpustop_handler () > at /usr/src/sys/amd64/amd64/mp_machdep.c:1432 > 1432 savectx(&stoppcbs[cpu]); > (kgdb) up 4 > #4 0xffffffff80733f79 in callout_process (now=3549882673091690) at > /usr/src/sys/kern/kern_timeout.c:443 > 443 tmp = LIST_FIRST(sc); > (kgdb) list > 438 } > 439 > 440 /* Iterate callwheel from firstb to nowb and then up to > lastb. */ > 441 do { > 442 sc = &cc->cc_callwheel[firstb & callwheelmask]; > 443 tmp = LIST_FIRST(sc); > 444 while (tmp != NULL) { > 445 /* Run the callout if present time within > allowed. */ > 446 if (tmp->c_time <= now) { > 447 /* > (kgdb) p cc_cpu[0] > $1 = {cc_lock = {lock_object = {lo_name = 0xffffffff80ccbec7 "callout", > lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, > mtx_lock = 4}, cc_exec_entity = {{cc_next = 0x0, cc_curr = 0x0, > ce_migration_func = 0, ce_migration_arg = 0x0, > ce_migration_cpu = 64, ce_migration_time = 0, ce_migration_prec = 0, > cc_cancel = false, cc_waiting = false}, { > cc_next = 0xffffffff812a7af0, cc_curr = 0x0, ce_migration_func = 0, > ce_migration_arg = 0x0, ce_migration_cpu = 64, > ce_migration_time = 0, ce_migration_prec = 0, cc_cancel = false, > cc_waiting = false}}, > cc_callout = 0xfffffe000069f000, cc_callwheel = 0xfffffe00007c1000, > cc_expireq = {tqh_first = 0x0, > tqh_last = 0xffffffff812a0510}, cc_callfree = {slh_first = > 0xfffffe00007c02c0}, cc_firstevent = 3549882673088716, > cc_lastscan = 3549882673091690, cc_cookie = 0xfffff800151f4b80, cc_bucket > = 6515} > (kgdb) p last > $2 = 3549882929381376 So, the bucket for 'cc_lastscan' (which is 'now' when this was called) is only 16 buckets behind the bucket for last. That doesn't seem like a lot of work to be done: (gdb) p (3549882673091690 >> (32 - 8)) $4 = 211589495 (gdb) p (3549882929381376 >> (32 - 8)) $5 = 211589511 (gdb) p $5 - $4 $6 = 16 OTOH, we know that cc_lastcan when this function was started was less than cc_firstevent. However, that is the same bucket as for 'cc_lastscan': (gdb) p (3549882673088716 >> (32 - 8)) $7 = 211589495 My only other thought is if a direct timeout routine ran for a long time. I just committed a change to current that can let you capture KTR traces of callout routines for use with schedgraph (r272757). Unfortunately, enabling KTR_SCHED can be slow. If you are up for trying it, I do think that building a kernel with KTR and KTR_SCHED enabled (KTR_COMPILE=KTR_SCHED and KTR_MASK=KTR_SCHED) with the kernel part of the commit I referenced above applied is the best bet to figure out why it is spinning so long. If you can try that (and if it doesn't slow things down too much) and get a panic with those options enabled, then capture the output of 'ktrdump -e /path/to/kernel -m /var/crash/vmcore.X -ct', we can use Src/tools/sched/schedgraph.py to look at that output to get a picture of what was going on just prior to the crash. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Oct 9 04:18:28 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43317A1D for ; Thu, 9 Oct 2014 04:18:28 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DE47D54 for ; Thu, 9 Oct 2014 04:18:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s994IRSi033073 for ; Thu, 9 Oct 2014 04:18:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 159629] [ipsec] [panic] kernel panic with IPsec in transport mode ; -current kernel Date: Thu, 09 Oct 2014 04:18:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.0-BETA1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 09 Oct 2014 04:18:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=159629 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved CC| |ae@FreeBSD.org Resolution|--- |Unable to Reproduce --- Comment #2 from Andrey V. Elsukov --- Works without panic on head/ and stable/9. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Oct 9 08:06:04 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3304519E for ; Thu, 9 Oct 2014 08:06:04 +0000 (UTC) Received: from COL004-OMC2S4.hotmail.com (col004-omc2s4.hotmail.com [65.55.34.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CB5676E for ; Thu, 9 Oct 2014 08:06:03 +0000 (UTC) Received: from COL127-W25 ([65.55.34.73]) by COL004-OMC2S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 9 Oct 2014 01:05:57 -0700 X-TMN: [ImwByoH6lLhIsIZCCmSBaGQwEj306CU3] X-Originating-Email: [deco33000@hotmail.com] Message-ID: From: Jog Lie To: Subject: Netmap. Example to understand? Date: Thu, 9 Oct 2014 10:05:56 +0200 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 09 Oct 2014 08:05:57.0165 (UTC) FILETIME=[DB0CCDD0:01CFE397] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 09 Oct 2014 08:06:04 -0000 Hello I have three boxes running linux or freebsd. A is a loadbalancer to b and c. Same network. A has three nics: one for internet=2C one connected with B and one connecte= d with C to avoid another switch for a small configuration. I wish to understand how netmap can help me saturating a 10Gbit link with a= i7 3930k (could be replaced by something less powerful if netmap allow big= perf jump). How can i select the nic to which i wish to send the packet? The read write= pattern is not clear to me. Will netfilter be completely bypassed hence ac= hieving high perf? I am in need for an example mates. Thanks a lot Bye = From owner-freebsd-net@FreeBSD.ORG Thu Oct 9 08:56:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BF0A9CE for ; Thu, 9 Oct 2014 08:56:57 +0000 (UTC) Received: from COL004-OMC2S2.hotmail.com (col004-omc2s2.hotmail.com [65.55.34.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 79CE7BE8 for ; Thu, 9 Oct 2014 08:56:57 +0000 (UTC) Received: from COL127-W11 ([65.55.34.71]) by COL004-OMC2S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 9 Oct 2014 01:56:51 -0700 X-TMN: [yetfwFpogWfz0qVgrwD6LtKAfnut6cWw] X-Originating-Email: [deco33000@hotmail.com] Message-ID: From: Jog Lie To: Subject: RE: Netmap. Example to understand? Date: Thu, 9 Oct 2014 10:56:50 +0200 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 09 Oct 2014 08:56:51.0010 (UTC) FILETIME=[F7489220:01CFE39E] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 09 Oct 2014 08:56:57 -0000 Ok got it! https://github.com/fichtner/netmap/blob/master/examples/bridge.c > From: deco33000@hotmail.com > To: freebsd-net@freebsd.org > Subject: Netmap. Example to understand? > Date: Thu=2C 9 Oct 2014 10:05:56 +0200 >=20 > Hello >=20 > I have three boxes running linux or freebsd. >=20 > A is a loadbalancer to b and c. Same network. > A has three nics: one for internet=2C one connected with B and one connec= ted with C to avoid another switch for a small configuration. >=20 > I wish to understand how netmap can help me saturating a 10Gbit link with= a i7 3930k (could be replaced by something less powerful if netmap allow b= ig perf jump). >=20 > How can i select the nic to which i wish to send the packet? The read wri= te pattern is not clear to me. Will netfilter be completely bypassed hence = achieving high perf? > I am in need for an example mates. > Thanks a lot > Bye > =20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe=2C send any mail to "freebsd-net-unsubscribe@freebsd.org" = From owner-freebsd-net@FreeBSD.ORG Thu Oct 9 21:02:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ED71FE1; Thu, 9 Oct 2014 21:02:12 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADA92AAA; Thu, 9 Oct 2014 21:02:11 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=[10.0.0.120]) by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XcGr8-00033L-DF; Thu, 09 Oct 2014 20:46:22 +0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: HEADS UP: Merging projects/ipfw to HEAD From: Alexander V. Chernikov In-Reply-To: <542FE9A7.9090208@FreeBSD.org> Date: Fri, 10 Oct 2014 01:02:05 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02957253-78AC-4CDF-AD48-86D219667F02@ipfw.ru> References: <542FE9A7.9090208@FreeBSD.org> To: "Alexander V. Chernikov" X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , freebsd-current@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 09 Oct 2014 21:02:12 -0000 On 04 Oct 2014, at 16:35, Alexander V. Chernikov = wrote: > Hi, >=20 > I'm going to merge projects/ipfw branch to HEAD in the middle of next = week. Merged in r 272840. >=20 > What has changed: >=20 > Main user-visible changes are related to tables: >=20 > * Tables are now identified by names, not numbers. There can be up to = 65k tables with up to 63-byte long names. > * Tables are now set-aware (default off), so you can switch/move them = atomically with rules. > * More functionality is supported (swap, lock, limits, user-level = lookup, batched add/del) by generic table code. > * New table types are added (flow) so you can match multiple packet = fields at once. > * Ability to add different type of lookup algorithms for particular = table type has been added. > * New table algorithms are added (cidr:hash, iface:array, number:array = and flow:hash) to make certain types of lookup more effective. > * Table value are now capable of holding multiple data fields for = different tablearg users >=20 > Some examples (see ipfw(8) manual page for the description): >=20 > 0:02 [2] zfscurr0# ipfw table fl2 create type = flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib > 0:02 [2] zfscurr0# ipfw table fl2 info > +++ table(fl2), set(0) +++ > kindex: 0, type: flow:src-ip,proto,dst-port > valtype: number, references: 0 > algorithm: flow:hash > items: 0, size: 280 > 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 > 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 > 0:02 [2] zfscurr0# ipfw table fl2 list > +++ table(fl2), set(0) +++ > 2a02:6b8::333,6,443 45000 > 10.0.0.92,6,80 22000 > 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 = flow 'table(fl2)' >=20 > ipfw table mi_test create type cidr algo "cidr:hash masks=3D/30,/64" > ipfw table mi_test add 10.0.0.8/30 > ipfw table mi_test add 2a02:6b8:b010::1/64 25 >=20 > # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 > added: 1.1.1.1/32 1111 > added: 2.2.2.2/32 2222 > # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 > exists: 2.2.2.2/32 2200 > added: 4.4.4.4/32 4444 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error but keeps inserted items > # ipfw table si list > +++ table(si), set(0) +++ > 1.1.1.1/32 1111 > 2.2.2.2/32 2222 > 4.4.4.4/32 4444 > # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 = 5.5.5.5/32 5555 > added(reverted): 3.3.3.3/32 3333 > exists: 4.4.4.4/32 4400 > ignored: 5.5.5.5/32 5555 > ipfw: Adding record failed: record already exists > ^^^^^ Returns error and reverts added records >=20 > Performance changes: > * Main ipfw lock was converted to rmlock > * Rule counters were separated from rule itself and made per-cpu. > * Radix table entries fits into 128 bytes > * struct ip_fw is now more compact so more rules will fit into 64 = bytes > * interface tables uses array of existing ifindexes for faster match >=20 > ABI changes: > All functionality supported by old ipfw(8) remains functional. Old & = new binaries can work together with the following restrictions: > * Tables named other than ^\d+$ are shown as table(65535) in ruleset = in old binaries > * I'm a bit unsure about "lookup src-port|dst-port N" case, something = may be broken here. Anyway, this can be fixed for MFC >=20 > Internal changes:. > Changing table ids to numbers resulted in format modification for most = sockopt codes. > Old sopt format was compact, but very hard to extend (no versioning, = inability to add more opcodes), so > * All relevant opcodes were converted to TLV-based versioned = IP_FW3-based codes. > * The remaining opcodes were also converted to be able to eliminate = all older opcodes at once > * All IP_FW3 handlers uses special API instead of calling sooptcopy* = directly to ease adding another communication methods > * struct ip_fw is now different for kernel and userland > * tablearg value has been changed to 0 to ease future extensions > * table "values" are now indexes in special value array which holds = extended data for given index > * Batched add/delete has been added to tables code > * Most changes has been done to permit batched rule addition. > * interface tracking API has been added (started on demand) to permit = effective interface tables operations > * O(1) skipto cache, currently turned off by default at compile-time = (eats 512K). >=20 > * Several steps has been made towards making libipfw: > * most of new functions were separated into "parse/prepare/show and = actuall-do-stuff" pieces (already merged). > * there are separate functions for parsing text string into "struct = ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). > * Probably some more less significant/forgotten features >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Thu Oct 9 21:31:35 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EFFFD9A; Thu, 9 Oct 2014 21:31:35 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 994A2E85; Thu, 9 Oct 2014 21:31:34 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id m15so2388074wgh.26 for ; Thu, 09 Oct 2014 14:31:32 -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=VI5z8XPfoURwbE9Go+dXCUDzwx6YvyyXMQ33fdnpx8Q=; b=AD6WXMroqK895JrLhRkLPhayzplWznC1kxufDOIiYb9aK/kgAYZvi98assK6miLtox /0WhA/GOb2Uc7KAK8vPME4WkmsH71mSR+Qg6OhSdUAHH03MzdKzeddw95JE2fwR2IYQf xDjVJYh9CCcpffGj37ITTtyoA679lyJgozyfluOAhsGewC/yxnMJoQDlG612oqJP+MBP XQCqae5GH207wbUWFSpuUQgG7gJbu5p8NLB9Uh+Ev2RbcI9Tt7CBaTktoC/1OVHf6LvK kV5xBahPKlrm1+z5IxXXHkkhKs2s9zbu/aRFosg3WQDYEay7uH1PQFqGaOi3yznHDPWl pDBA== MIME-Version: 1.0 X-Received: by 10.180.79.41 with SMTP id g9mr479780wix.75.1412890292641; Thu, 09 Oct 2014 14:31:32 -0700 (PDT) Received: by 10.217.67.201 with HTTP; Thu, 9 Oct 2014 14:31:32 -0700 (PDT) In-Reply-To: <2077446.sYcZo9xEXb@ralph.baldwin.cx> References: <1410203348.1343.1.camel@bruno> <201410071428.15753.jhb@freebsd.org> <2077446.sYcZo9xEXb@ralph.baldwin.cx> Date: Thu, 9 Oct 2014 14:31:32 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 09 Oct 2014 21:31:35 -0000 On Wed, Oct 8, 2014 at 12:29 PM, John Baldwin wrote: > My only other thought is if a direct timeout routine ran for a long time. > > I just committed a change to current that can let you capture KTR traces of > callout routines for use with schedgraph (r272757). Unfortunately, > enabling KTR_SCHED can be slow. If you are up for trying it, I do think > that > building a kernel with KTR and KTR_SCHED enabled (KTR_COMPILE=KTR_SCHED and > KTR_MASK=KTR_SCHED) with the kernel part of the commit I referenced above > applied is the best bet to figure out why it is spinning so long. If you > can > try that (and if it doesn't slow things down too much) and get a panic with > those options enabled, then capture the output of > 'ktrdump -e /path/to/kernel -m /var/crash/vmcore.X -ct', we can use > Src/tools/sched/schedgraph.py to look at that output to get a picture of > what > was going on just prior to the crash. > > -- > John Baldwin > As luck would have it.. caught one of the boxes with the new KTR code/options after only an hour. Crashed in the same way w tid 100003 and looking the same in callout_process spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid 100003) too long spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid 100003) too long #4 0xffffffff8070d6fa in callout_process (now=7915682202423) at /usr/src/sys/kern/kern_ timeout.c:490 The ktrdump oddly only seems to have the last 702, though debug.ktr.entries is set to 1024. It appears the buffer may also start after 100003 had already hung? I've bumped debug.ktr.entries up in case we don't have enough history here. http://nitrology.com/ktrdump-spinlock.txt Jason From owner-freebsd-net@FreeBSD.ORG Thu Oct 9 22:29:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FBF2658 for ; Thu, 9 Oct 2014 22:29:34 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DA3164D for ; Thu, 9 Oct 2014 22:29:33 +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 s99MTRVp062746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2014 15:29:27 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s99MTQt8062745; Thu, 9 Oct 2014 15:29:26 -0700 (PDT) (envelope-from jmg) Date: Thu, 9 Oct 2014 15:29:26 -0700 From: John-Mark Gurney To: elof2@sentor.se Subject: Re: Unable to kill a non-zombie process with -9 Message-ID: <20141009222926.GC1852@funkthat.com> Mail-Followup-To: elof2@sentor.se, freebsd-net , snort-devel mailinglist References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 09 Oct 2014 15:29:27 -0700 (PDT) Cc: freebsd-net , snort-devel mailinglist X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 09 Oct 2014 22:29:34 -0000 elof2@sentor.se wrote this message on Wed, Oct 08, 2014 at 13:30 +0200: > > I guess this is a bug report for FreeBSD 10.0. > > > > Sometimes I can't kill my snort process on FreeBSD 10.0. > It won't die, even with kill -9. > > I'm not talking about a zombie process. Snort is a process that should > die normally. > I've run snort on over 100 nodes since FreeBSD v6.x and I've never seen > this behavior until now in FreeBSD 10.0. > > > Example: > > #ps faxuw > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > COMMAND > root 49222 53.4 2.2 492648 183012 - Rs 11:46AM 7:05.59 > /usr/local/bin/snort -q -D -c snort.conf > root 47937 0.0 2.2 488552 182864 - Ts 10:56AM 29:35.98 > /usr/local/bin/snort -q -D -c snort.conf What is the MWCHAN? add l to the ps command... > The pid 47937 has been killed (repeatedly) with -9. > Its status is "Ts" meaning it is Stopped. have you tried to kill -CONT to resume it? > But it won't actually die and disappear. The only way to get rid of it > seem to be to reboot the machine. :-( > > (pid 49222 is the new process that was started after 47937 was killed) > > > The problem doesn't happen all the time and I haven't found any patterns > as to when it does. :-( > If I restart snort once every day, it fails to die approximately 2-4 times > per month. > Even though the problem doesn't happen on every kill, it is a definately a > recurring event. Can you run kgdb on the machine? (yes, it works on a live machine), use info threads to find the thread id, and then use thread to switch to it, and run bt to get a back trace... > I began to see it on a heavily loaded 10GE sensor, so I thought it could > have something to do with the ix driver, or the heavy load. > But now another FreeBSD 10.0-sensor had the exact same problem, and this > sensor don't have any 10GE NICs. In fact, this sensor has been running > just fine with both FreeBSD 9.1 and 9.3 for the past years. Snort has > always terminated correctly! After I reinstalled this machine with FreeBSD > 10.0 last friday, snort has then terminated correctly every day until > today, when it failed with the above pid 47937. (this sensor use the 'em' > driver, not 'ixgbe') > > I'm running snort with the same configuration, settings, version, daq, > libs, etc on 10.0 as I do on 9.3. > None of the 9.3 sensors have this problem, so it has to be something new > in FreeBSD 10.0. -- 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 Thu Oct 9 22:56:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09F24E16 for ; Thu, 9 Oct 2014 22:56:40 +0000 (UTC) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1B8D990 for ; Thu, 9 Oct 2014 22:56:39 +0000 (UTC) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id B9B3898B20 for ; Thu, 9 Oct 2014 15:47:38 -0700 (PDT) Received: from EX13-CAS-003.vmware.com (EX13-CAS-003.vmware.com [10.113.191.53]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id B4CD041666 for ; Thu, 9 Oct 2014 15:47:38 -0700 (PDT) Received: from EX13-MBX-003.vmware.com (10.113.191.23) by EX13-MBX-013.vmware.com (10.113.191.33) with Microsoft SMTP Server (TLS) id 15.0.775.38; Thu, 9 Oct 2014 15:47:27 -0700 Received: from EX13-MBX-003.vmware.com ([fe80::8cf0:b7d5:ffd7:602d]) by EX13-MBX-003.vmware.com ([fe80::8cf0:b7d5:ffd7:602d%15]) with mapi id 15.00.0775.031; Thu, 9 Oct 2014 15:47:27 -0700 From: Madhusudhan Ravi To: "freebsd-net@freebsd.org" Subject: TCP receive window management Thread-Topic: TCP receive window management Thread-Index: AQHP5BL/Sq2gqdLv0UCkeloj8ccyCw== Date: Thu, 9 Oct 2014 22:47:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.113.160.246] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 09 Oct 2014 22:56:40 -0000 I have a question regarding the freeBSD receive window advertisement and up= dating sender side flow control state based on this. Is it expected that a retransmitted packet not carry an updated receive win= dow? The following are the state variables used for maintaining a peer's rcv win= dow state on the sender side. snd_wnd, snd_wl1, snd_wl2. In tcp_input at th= e label step6: where these states are updated there are checks which make s= ure rcv window is not updated by old segments. if ((thflags & TH_ACK) && (SEQ_LT(tp->snd_wl1, th->th_seq) || (tp->snd_wl1 =3D=3D th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) || (tp->snd_wl2 =3D=3D th->th_ack && tiwin > tp->snd_wnd))))) { Based on the above checks for the case of a fast retransmitted packet that = does ack additional data ((SEQ_LT(tp->snd_wl2, th->th_ack) is TRUE) and ha= s the latest rcv window. th_seq could be < snd_wl1 and in this case rcv win= dow is not updated to the latest one. Is this intentional or is there somet= hing that I am missing. Thanks Madhu From owner-freebsd-net@FreeBSD.ORG Fri Oct 10 15:58:05 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D88D552B for ; Fri, 10 Oct 2014 15:58:05 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B01B4C4F for ; Fri, 10 Oct 2014 15:58:05 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 26E0AB91F; Fri, 10 Oct 2014 11:58:01 -0400 (EDT) From: John Baldwin To: Jason Wolfe Subject: Re: ixgbe(4) spin lock held too long Date: Fri, 10 Oct 2014 11:53:30 -0400 Message-ID: <3567780.Mf6fMnzmYG@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: References: <1410203348.1343.1.camel@bruno> <2077446.sYcZo9xEXb@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 10 Oct 2014 11:58:01 -0400 (EDT) Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 10 Oct 2014 15:58:05 -0000 On Thursday, October 09, 2014 02:31:32 PM Jason Wolfe wrote: > On Wed, Oct 8, 2014 at 12:29 PM, John Baldwin wrote: > > My only other thought is if a direct timeout routine ran for a long time. > > > > I just committed a change to current that can let you capture KTR traces > > of > > callout routines for use with schedgraph (r272757). Unfortunately, > > enabling KTR_SCHED can be slow. If you are up for trying it, I do think > > that > > building a kernel with KTR and KTR_SCHED enabled (KTR_COMPILE=KTR_SCHED > > and > > KTR_MASK=KTR_SCHED) with the kernel part of the commit I referenced above > > applied is the best bet to figure out why it is spinning so long. If you > > can > > try that (and if it doesn't slow things down too much) and get a panic > > with > > those options enabled, then capture the output of > > 'ktrdump -e /path/to/kernel -m /var/crash/vmcore.X -ct', we can use > > Src/tools/sched/schedgraph.py to look at that output to get a picture of > > what > > was going on just prior to the crash. > > > > -- > > John Baldwin > > As luck would have it.. caught one of the boxes with the new KTR > code/options after only an hour. Crashed in the same way w tid 100003 and > looking the same in callout_process > > spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid > 100003) too long > spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid > 100003) too long > > #4 0xffffffff8070d6fa in callout_process (now=7915682202423) at > /usr/src/sys/kern/kern_ > timeout.c:490 > > The ktrdump oddly only seems to have the last 702, though debug.ktr.entries > is set to 1024. It appears the buffer may also start after 100003 had > already hung? I've bumped debug.ktr.entries up in case we don't have > enough history here. > > http://nitrology.com/ktrdump-spinlock.txt Hmm, schedgraph.py chokes on this, but it's a bit interesting. It seems that in this time sample, CPUs 1, 2, 4, and 5 were constantly running ixgbe interrupt handlers. No actual thread state changes are logged (which is why schedgraph choked). Try setting the sysctl 'net.inet.tcp.per_cpu_timers' to 1 and see if that makes a difference. I'm guessing they are all contending on the default callout lock which is causing your headache. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 06:19:23 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D87C85B; Sat, 11 Oct 2014 06:19:23 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A695BD2; Sat, 11 Oct 2014 06:19:22 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cc10so5862896wib.4 for ; Fri, 10 Oct 2014 23:19:20 -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=ocEQMeRCSYvRwBPaB3CmdYj3u5YOoNXM6kd4AngBIfY=; b=mL3JijZc3Kfx6jf9Fn57XCu5fHWzjUdKrjjsZOXV2Au2fDjDv57gAiZ5D9FvqhlT/O vVt0fKFUEzaLX5CM79JfwqR9r74W4wiXnzQV9YTKR/+f0XAlCVTV4VqH24ALYq6uRrIK 0hcCG0Vmcfei22bQ+tcs74o5/W/C/AGSDb2GjObtcGELGH9pDtm8rSu+Qx3EqXcEXZro rxKUmn660+TjEI03rrVgI4gW5bqcyvVJE+flO4+4AibH1rLBg0QJd0HmzXNpu5Nd5t9x ZKZgnXnF3WmIacYV7orc5g+Dui5vl63fhVdeNtkzGBkOjrKJoq8dHGVaFF6voGsazfT6 suZw== MIME-Version: 1.0 X-Received: by 10.181.12.14 with SMTP id em14mr9152067wid.9.1413008359895; Fri, 10 Oct 2014 23:19:19 -0700 (PDT) Received: by 10.217.67.201 with HTTP; Fri, 10 Oct 2014 23:19:19 -0700 (PDT) In-Reply-To: <3567780.Mf6fMnzmYG@ralph.baldwin.cx> References: <1410203348.1343.1.camel@bruno> <2077446.sYcZo9xEXb@ralph.baldwin.cx> <3567780.Mf6fMnzmYG@ralph.baldwin.cx> Date: Fri, 10 Oct 2014 23:19:19 -0700 Message-ID: Subject: Re: ixgbe(4) spin lock held too long From: Jason Wolfe To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Sean Bruno , freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 06:19:23 -0000 On Fri, Oct 10, 2014 at 8:53 AM, John Baldwin wrote: > On Thursday, October 09, 2014 02:31:32 PM Jason Wolfe wrote: > > On Wed, Oct 8, 2014 at 12:29 PM, John Baldwin wrote: > > > My only other thought is if a direct timeout routine ran for a long > time. > > > > > > I just committed a change to current that can let you capture KTR > traces > > > of > > > callout routines for use with schedgraph (r272757). Unfortunately, > > > enabling KTR_SCHED can be slow. If you are up for trying it, I do > think > > > that > > > building a kernel with KTR and KTR_SCHED enabled (KTR_COMPILE=KTR_SCHED > > > and > > > KTR_MASK=KTR_SCHED) with the kernel part of the commit I referenced > above > > > applied is the best bet to figure out why it is spinning so long. If > you > > > can > > > try that (and if it doesn't slow things down too much) and get a panic > > > with > > > those options enabled, then capture the output of > > > 'ktrdump -e /path/to/kernel -m /var/crash/vmcore.X -ct', we can use > > > Src/tools/sched/schedgraph.py to look at that output to get a picture > of > > > what > > > was going on just prior to the crash. > > > > > > -- > > > John Baldwin > > > > As luck would have it.. caught one of the boxes with the new KTR > > code/options after only an hour. Crashed in the same way w tid 100003 > and > > looking the same in callout_process > > > > spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid > > 100003) too long > > spin lock 0xffffffff81262d00 (callout) held by 0xfffff800151fe000 (tid > > 100003) too long > > > > #4 0xffffffff8070d6fa in callout_process (now=7915682202423) at > > /usr/src/sys/kern/kern_ > > timeout.c:490 > > > > The ktrdump oddly only seems to have the last 702, though > debug.ktr.entries > > is set to 1024. It appears the buffer may also start after 100003 had > > already hung? I've bumped debug.ktr.entries up in case we don't have > > enough history here. > > > > http://nitrology.com/ktrdump-spinlock.txt > > Hmm, schedgraph.py chokes on this, but it's a bit interesting. It seems > that > in this time sample, CPUs 1, 2, 4, and 5 were constantly running ixgbe > interrupt handlers. No actual thread state changes are logged (which is > why > schedgraph choked). > > Try setting the sysctl 'net.inet.tcp.per_cpu_timers' to 1 and see if that > makes a difference. I'm guessing they are all contending on the default > callout lock which is causing your headache. > > -- > John Baldwin > net.inet.tcp.per_cpu_timers=1 triggered some other fun :) Saw this same panic across a handful of machines: panic: tcp_setpersist: retransmit pending cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe1f9e9ab800 panic() at panic+0x155/frame 0xfffffe1f9e9ab880 tcp_setpersist() at tcp_setpersist+0xa3/frame 0xfffffe1f9e9ab8b0 tcp_timer_persist() at tcp_timer_persist+0x176/frame 0xfffffe1f9e9ab8e0 softclock_call_cc() at softclock_call_cc+0x1ce/frame 0xfffffe1f9e9ab9e0 softclock() at softclock+0x44/frame 0xfffffe1f9e9aba00 intr_event_execute_handlers() at intr_event_execute_handlers+0x83/frame 0xfffffe1f9e9aba30 ithread_loop() at ithread_loop+0x96/frame 0xfffffe1f9e9aba70 fork_exit() at fork_exit+0x71/frame 0xfffffe1f9e9abab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe1f9e9abab0 --- trap 0, rip = 0, rsp = 0xfffffe1f9e9abb70, rbp = 0 --- (kgdb) up 3 #3 0xffffffff808467d3 in tcp_setpersist (tp=) at /usr/src/sys/netinet/tcp_output.c:1619 1619 panic("tcp_setpersist: retransmit pending"); (kgdb) list 1614 int t = ((tp->t_srtt >> 2) + tp->t_rttvar) >> 1; 1615 int tt; 1616 1617 tp->t_flags &= ~TF_PREVVALID; 1618 if (tcp_timer_active(tp, TT_REXMT)) 1619 panic("tcp_setpersist: retransmit pending"); 1620 /* 1621 * Start/restart persistance timer. 1622 */ 1623 TCPT_RANGESET(tt, t * tcp_backoff[tp->t_rxtshift], I have debug.ktr.entries set to 204800 on the machines compiled with KTR options, maybe a bit more history can provide some extra context. Jason From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 14:15:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17AAEAF5; Sat, 11 Oct 2014 14:15:09 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3924C72; Sat, 11 Oct 2014 14:15:07 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s9BEF5XA046649; Sat, 11 Oct 2014 07:15:05 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s9BEF58c046648; Sat, 11 Oct 2014 07:15:05 -0700 (PDT) (envelope-from david) Date: Sat, 11 Oct 2014 07:15:05 -0700 From: David Wolfskill To: "Alexander V. Chernikov" Subject: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD] Message-ID: <20141011141505.GA46277@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org References: <542FE9A7.9090208@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <542FE9A7.9090208@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , freebsd-current@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 14:15:09 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote: > Hi, >=20 > I'm going to merge projects/ipfw branch to HEAD in the middle of next wee= k. > .... OK; I was able to build & install head @r272938 this morning on my laptop; on reboot, I was greeted by a panic. Now, this is a laptop, so I don't have a serial console -- but I was able to "call doadump", then reboot with the wireless NIC disabled (to avoid the panic) and get the dump & core.txt captured. Here's the first chunk of the core.txt file: localhost dumped core - see /var/crash/vmcore.0 Sat Oct 11 07:02:26 PDT 2014 FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1392 r272938M/272938:= 1100037: Sat Oct 11 05:44:30 PDT 2014 root@g1-235.catwhisker.org:/commo= n/S4/obj/usr/src/sys/CANARY i386 panic: resize_storage() notify failure GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: resize_storage() notify failure cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(c10ebfd8,d1070720,fc,10000000,1,...) at 0xc0528cdd = =3D db_trace_self_wrapper+0x2d/frame 0xfa0cc508 kdb_backtrace(c12a9e27,0,c111af52,fa0cc5dc,fa0cc598,...) at 0xc0b22180 =3D = kdb_backtrace+0x30/frame 0xfa0cc570 vpanic(c1447c52,100,c111af52,fa0cc5dc,fa0cc5dc,...) at 0xc0ae7b8d =3D vpani= c+0x11d/frame 0xfa0cc5ac kassert_panic(c111af52,fa0cc6f8,223,1e8,c0b71417,...) at 0xc0ae7a6a =3D kas= sert_panic+0xea/frame 0xfa0cc5d0 ipfw_link_table_values(c1518498,fa0cc6f8,25a,fa0cc728,c1469c5c,...) at 0xc0= d25cfd =3D ipfw_link_table_values+0x5ed/frame 0xfa0cc6a0 add_table_entry(c1518498,fa0cc7f0,fa0cc800,0,1,...) at 0xc0d1be78 =3D add_t= able_entry+0x348/frame 0xfa0cc7c8 manage_table_ent_v1(c1518498,fa0cca08,fa0cc870,8,c0d17710,...) at 0xc0d202b= 9 =3D manage_table_ent_v1+0x1c9/frame 0xfa0cc828 ipfw_ctl3(fa0ccbe0,2,fa0ccba8,c0a9ffc4,fa0ccbd0,...) at 0xc0d1834d =3D ipfw= _ctl3+0xacd/frame 0xfa0ccb20 rip_ctloutput(d2432dc0,fa0ccbe0,ffffffff,200007f,1fffff,...) at 0xc0c3cf49 = =3D rip_ctloutput+0x299/frame 0xfa0ccb48 sogetopt(d2432dc0,fa0ccbe0,fa0ccbd0,0,fa0ccbf8,...) at 0xc0b6c670 =3D soget= opt+0xb0/frame 0xfa0ccba8 kern_getsockopt(d03afc40,4,0,30,bfbfd850,...) at 0xc0b71556 =3D kern_getsoc= kopt+0x116/frame 0xfa0ccc0c sys_getsockopt(d03afc40,fa0cccc8,c12ab55e,d5,c1455210,...) at 0xc0b71417 = =3D sys_getsockopt+0x67/frame 0xfa0ccc40 syscall(fa0ccd08) at 0xc0f7c76b =3D syscall+0x31b/frame 0xfa0cccfc Xint0x80_syscall() at 0xc0f665b1 =3D Xint0x80_syscall+0x21/frame 0xfa0cccfc --- syscall (118, FreeBSD ELF32, sys_getsockopt), eip =3D 0x2815a3c7, esp = =3D 0xbfbfd2e4, ebp =3D 0xbfbfd300 --- KDB: enter: panic Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. Loaded symbols for /boot/kernel/iwn5000fw.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. Loaded symbols for /boot/kernel/tmpfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. Loaded symbols for /boot/kernel/linprocfs.ko.symbols #0 doadump (textdump=3D0) at pcpu.h:233 233 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=3D0) at pcpu.h:233 #1 0xc0526acd in db_fncall (dummy1=3D-99826980, dummy2=3D0, dummy3=3D15738= 88,=20 dummy4=3D0xfa0cc2b4 "\036\211\220=C0=B8\026M=C1") at /usr/src/sys/ddb/db_command.c:578 #2 0xc05267ab in db_command (cmd_table=3D) at /usr/src/sys/ddb/db_command.c:449 #3 0xc05264f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0xc0528e20 in db_trap (type=3D,=20 code=3D) at /usr/src/sys/ddb/db_main.c:251 #5 0xc0b226f4 in kdb_trap (type=3D,=20 code=3D, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xc0f7ba87 in trap (frame=3D) at /usr/src/sys/i386/i386/trap.c:693 #7 0xc0f6651c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 #8 0xc0b21f7d in kdb_enter (why=3D0xc10e77dd "panic",=20 msg=3D) at cpufunc.h:71 #9 0xc0ae7bb1 in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:739 #10 0xc0ae7a6a in kassert_panic (fmt=3D) at /usr/src/sys/kern/kern_shutdown.c:634 #11 0xc0d25cfd in ipfw_link_table_values (ch=3D0x0, ts=3D0xfa0cc6f8) at /usr/src/sys/netpfil/ipfw/ip_fw_table_value.c:560 #12 0xc0d1be78 in add_table_entry (ch=3D0xc1518498, tei=3D0xfa0cc800,=20 flags=3D0 '\0', count=3D1) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:6= 20 #13 0xc0d202b9 in manage_table_ent_v1 (op3=3D,=20 sd=3D) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:= 1038 #14 0xc0d1834d in ipfw_ctl3 (sopt=3D0xfa0ccbe0) at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:2723 #15 0xc0c3cf49 in rip_ctloutput (so=3D, sopt=3D0xfa0cc= be0) at /usr/src/sys/netinet/raw_ip.c:583 #16 0xc0b6c670 in sogetopt (so=3D0xd2432dc0, sopt=3D0xfa0ccbe0) at /usr/src/sys/kern/uipc_socket.c:2721 #17 0xc0b71556 in kern_getsockopt (s=3D,=20 level=3D, name=3D,=20 val=3D, valseg=3D,=20 valsize=3D) at /usr/src/sys/kern/uipc_syscalls.c:1= 589 #18 0xc0b71417 in sys_getsockopt (uap=3D0xfa0cccc8) at /usr/src/sys/kern/uipc_syscalls.c:1535 #19 0xc0f7c76b in syscall (frame=3D) at subr_syscall.c= :133 #20 0xc0f665b1 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:269 #21 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb)=20 I'll be happy to poke around more, test patches, .... The "poking" will likely be a bit on the slow side, since I won't have connectivity while the machine is running head (until the issue is circumvented, at least); as I type, it's running stable/9 (also just built today). And yes, since it's a laptop, and it's thus subject to being connected to networks I don't control, I run IPFW on it -- same rulesets & tables whether it's running stable/9, stable/10, or head. Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUOTtoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7zp4QAI7bvb/8tCVS7oM9PckTFKf4 79mT4Q6XFvKx55oOx128I/DVHLPkXv/Z6Vtvhb4TVavoMlwsCHju84Wd7pwfUddK ePGY4k4h179xcn3puo2nW2HCrt1JB/EDGEPFOqRu0eegwOA+cHmuL7OLLQ6GrESE iCYXdLtjmYluOplWzuv4jGLgeYtncULumcrWqKbZIMbqLYFTqKMPtyE2cLsTQgwz tEEvz5TQ7KwMJmATLprJMKzd7Y8ZjRCONHd8DGoPz5crI0IN0H7X/wBvSZ+F/F/H 3pJROSdDT5x9uwPQ9U0T/a3iktliX85i5PPT7y2i+Inzd6GD60CcLQF3s7cdw5V8 Sykqt25Y25kMT9K00JTGk7qr2fXcWAZgJx1aPWdHyp6Oy4AgUxh/oIaJmQC1pcHd Pu4tW6xlZpytxdTaUgEDRFJ3vvPdkmrIEmeWLq5btlCWvK/W6A3LsKPxiAqD30Ky 3WF1vAKrOh6wLarQp7WvZK/PBETFYIcACFdawy/4Q6snYz5XayTvvjEUVqGPOKqv 4IbsPJqIqq8z2xATTgumyqOkFAKo1TxMSDR/UeoVYhN8NLDmdw+O8a8amulYIDcK Oy9vWZJC7vFzItYKGoEP+WUP6Hx+saq6Vl1YDA7qRVaOj2ED+Q7aLtI1rknorHQu 4EVLauLiBApu4g1Nn1w1 =QWE5 -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 14:42:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2E90221; Sat, 11 Oct 2014 14:42:38 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B561F16; Sat, 11 Oct 2014 14:42:38 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xctsp-0008IR-RQ; Sat, 11 Oct 2014 14:26:43 +0400 Message-ID: <5439418A.5050903@FreeBSD.org> Date: Sat, 11 Oct 2014 18:41:14 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: David Wolfskill , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org Subject: Re: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD] References: <542FE9A7.9090208@FreeBSD.org> <20141011141505.GA46277@albert.catwhisker.org> In-Reply-To: <20141011141505.GA46277@albert.catwhisker.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 14:42:38 -0000 On 11.10.2014 18:15, David Wolfskill wrote: > On Sat, Oct 04, 2014 at 04:35:51PM +0400, Alexander V. Chernikov wrote: >> Hi, >> >> I'm going to merge projects/ipfw branch to HEAD in the middle of next week. >> .... > OK; I was able to build & install head @r272938 this morning on my > laptop; on reboot, I was greeted by a panic. Ups. Not the best greeting, definitely. Can you send me ipfw ruleset? > > Now, this is a laptop, so I don't have a serial console -- but I was > able to "call doadump", then reboot with the wireless NIC disabled (to Do you have some hooks to run ipfw on iface-up? > avoid the panic) and get the dump & core.txt captured. > > Here's the first chunk of the core.txt file: > > localhost dumped core - see /var/crash/vmcore.0 > > Sat Oct 11 07:02:26 PDT 2014 > > FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1392 r272938M/272938:1100037: Sat Oct 11 05:44:30 PDT 2014 root@g1-235.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > panic: resize_storage() notify failure > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > panic: resize_storage() notify failure > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper(c10ebfd8,d1070720,fc,10000000,1,...) at 0xc0528cdd = db_trace_self_wrapper+0x2d/frame 0xfa0cc508 > kdb_backtrace(c12a9e27,0,c111af52,fa0cc5dc,fa0cc598,...) at 0xc0b22180 = kdb_backtrace+0x30/frame 0xfa0cc570 > vpanic(c1447c52,100,c111af52,fa0cc5dc,fa0cc5dc,...) at 0xc0ae7b8d = vpanic+0x11d/frame 0xfa0cc5ac > kassert_panic(c111af52,fa0cc6f8,223,1e8,c0b71417,...) at 0xc0ae7a6a = kassert_panic+0xea/frame 0xfa0cc5d0 > ipfw_link_table_values(c1518498,fa0cc6f8,25a,fa0cc728,c1469c5c,...) at 0xc0d25cfd = ipfw_link_table_values+0x5ed/frame 0xfa0cc6a0 > add_table_entry(c1518498,fa0cc7f0,fa0cc800,0,1,...) at 0xc0d1be78 = add_table_entry+0x348/frame 0xfa0cc7c8 > manage_table_ent_v1(c1518498,fa0cca08,fa0cc870,8,c0d17710,...) at 0xc0d202b9 = manage_table_ent_v1+0x1c9/frame 0xfa0cc828 > ipfw_ctl3(fa0ccbe0,2,fa0ccba8,c0a9ffc4,fa0ccbd0,...) at 0xc0d1834d = ipfw_ctl3+0xacd/frame 0xfa0ccb20 > rip_ctloutput(d2432dc0,fa0ccbe0,ffffffff,200007f,1fffff,...) at 0xc0c3cf49 = rip_ctloutput+0x299/frame 0xfa0ccb48 > sogetopt(d2432dc0,fa0ccbe0,fa0ccbd0,0,fa0ccbf8,...) at 0xc0b6c670 = sogetopt+0xb0/frame 0xfa0ccba8 > kern_getsockopt(d03afc40,4,0,30,bfbfd850,...) at 0xc0b71556 = kern_getsockopt+0x116/frame 0xfa0ccc0c > sys_getsockopt(d03afc40,fa0cccc8,c12ab55e,d5,c1455210,...) at 0xc0b71417 = sys_getsockopt+0x67/frame 0xfa0ccc40 > syscall(fa0ccd08) at 0xc0f7c76b = syscall+0x31b/frame 0xfa0cccfc > Xint0x80_syscall() at 0xc0f665b1 = Xint0x80_syscall+0x21/frame 0xfa0cccfc > --- syscall (118, FreeBSD ELF32, sys_getsockopt), eip = 0x2815a3c7, esp = 0xbfbfd2e4, ebp = 0xbfbfd300 --- > KDB: enter: panic > > Reading symbols from /boot/kernel/linux.ko.symbols...done. > Loaded symbols for /boot/kernel/linux.ko.symbols > Reading symbols from /boot/kernel/coretemp.ko.symbols...done. > Loaded symbols for /boot/kernel/coretemp.ko.symbols > Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. > Loaded symbols for /boot/kernel/iwn5000fw.ko.symbols > Reading symbols from /boot/modules/nvidia.ko...done. > Loaded symbols for /boot/modules/nvidia.ko > Reading symbols from /boot/kernel/tmpfs.ko.symbols...done. > Loaded symbols for /boot/kernel/tmpfs.ko.symbols > Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. > Loaded symbols for /boot/kernel/fdescfs.ko.symbols > Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. > Loaded symbols for /boot/kernel/linprocfs.ko.symbols > #0 doadump (textdump=0) at pcpu.h:233 > 233 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=0) at pcpu.h:233 > #1 0xc0526acd in db_fncall (dummy1=-99826980, dummy2=0, dummy3=1573888, > dummy4=0xfa0cc2b4 "\036\211\220À¸\026MÁ") > at /usr/src/sys/ddb/db_command.c:578 > #2 0xc05267ab in db_command (cmd_table=) > at /usr/src/sys/ddb/db_command.c:449 > #3 0xc05264f0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 > #4 0xc0528e20 in db_trap (type=, > code=) at /usr/src/sys/ddb/db_main.c:251 > #5 0xc0b226f4 in kdb_trap (type=, > code=, tf=) > at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xc0f7ba87 in trap (frame=) > at /usr/src/sys/i386/i386/trap.c:693 > #7 0xc0f6651c in calltrap () at /usr/src/sys/i386/i386/exception.s:169 > #8 0xc0b21f7d in kdb_enter (why=0xc10e77dd "panic", > msg=) at cpufunc.h:71 > #9 0xc0ae7bb1 in vpanic (fmt=, ap=) > at /usr/src/sys/kern/kern_shutdown.c:739 > #10 0xc0ae7a6a in kassert_panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:634 > #11 0xc0d25cfd in ipfw_link_table_values (ch=0x0, ts=0xfa0cc6f8) > at /usr/src/sys/netpfil/ipfw/ip_fw_table_value.c:560 > #12 0xc0d1be78 in add_table_entry (ch=0xc1518498, tei=0xfa0cc800, > flags=0 '\0', count=1) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:620 > #13 0xc0d202b9 in manage_table_ent_v1 (op3=, > sd=) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:1038 > #14 0xc0d1834d in ipfw_ctl3 (sopt=0xfa0ccbe0) > at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:2723 > #15 0xc0c3cf49 in rip_ctloutput (so=, sopt=0xfa0ccbe0) > at /usr/src/sys/netinet/raw_ip.c:583 > #16 0xc0b6c670 in sogetopt (so=0xd2432dc0, sopt=0xfa0ccbe0) > at /usr/src/sys/kern/uipc_socket.c:2721 > #17 0xc0b71556 in kern_getsockopt (s=, > level=, name=, > val=, valseg=, > valsize=) at /usr/src/sys/kern/uipc_syscalls.c:1589 > #18 0xc0b71417 in sys_getsockopt (uap=0xfa0cccc8) > at /usr/src/sys/kern/uipc_syscalls.c:1535 > #19 0xc0f7c76b in syscall (frame=) at subr_syscall.c:133 > #20 0xc0f665b1 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:269 > #21 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > (kgdb) > > > I'll be happy to poke around more, test patches, .... The "poking" will > likely be a bit on the slow side, since I won't have connectivity while > the machine is running head (until the issue is circumvented, at least); > as I type, it's running stable/9 (also just built today). And yes, > since it's a laptop, and it's thus subject to being connected to > networks I don't control, I run IPFW on it -- same rulesets & tables > whether it's running stable/9, stable/10, or head. > > Peace, > david From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 15:59:55 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7774F555; Sat, 11 Oct 2014 15:59:55 +0000 (UTC) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2013883F; Sat, 11 Oct 2014 15:59:54 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.9/8.14.9) with ESMTP id s9BFxrib047071; Sat, 11 Oct 2014 08:59:53 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.9/8.14.9/Submit) id s9BFxrXG047070; Sat, 11 Oct 2014 08:59:53 -0700 (PDT) (envelope-from david) Date: Sat, 11 Oct 2014 08:59:53 -0700 From: David Wolfskill To: "Alexander V. Chernikov" Subject: Re: panic: resize_storage() notify failure [Was: HEADS UP: Merging projects/ipfw to HEAD] Message-ID: <20141011155953.GY1295@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HQLHrCACpVdwMl/9" Content-Disposition: inline In-Reply-To: <54394728.2090402@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-net@freebsd.org" , freebsd-current@freebsd.org, freebsd-ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 15:59:55 -0000 --HQLHrCACpVdwMl/9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 11, 2014 at 07:05:12PM +0400, Alexander V. Chernikov wrote: > ... > Whoops. My bad. > It should be fixed in r272940. > ... Confirmed: I'm not running: FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #1393 r272938M/272938:= 1100037: Sat Oct 11 08:45:34 PDT 2014 root@localhost:/common/S4/obj/usr= /src/sys/CANARY i386 after having hand-applied the patch in r272940, rebuilt, reinstalled, and rebooted. Thank you for the quick work! :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --HQLHrCACpVdwMl/9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUOVP4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RThEMDY4QTIxMjc1MDZFRDIzODYzRTc4 QTY3RjlDOERFRjQxOTNCAAoJEIpn+cje9Bk7/O4P/jwuT6lUeZ/L0zMk8fLt9GiT cc0aonyMCSYllZLJbhOXuN0u6aGrV5DZKTRjFLBJgwqwbm25TevVEdxdUlDXseyo 2+nQokAtD+kc4mutk3yKCREZcgnOvavICma5WX85uOHRRvCsDsN8iWSfehEdidcu VGHWwc5/Ny+dy/VYDAR3sUQH5w4P6ngFfL5Ij8JTJdyXQ3gZ2nb+bIpvMy7p8FLw JQBCg8qZObt0+/mtI1DU5tEoPOzDvw4AQL0Jezz+TxDBF5kS8G2g041ZBonpXdVz Qiz0t4TtgdGBFqc/73OFMd517xAHYjzDbTWRvcUDFbccejLuIonGyG3k5yvwlcDY eml6sqRZucZKXdg0eCUd06sKXmE1+jbktrtr6Nv8b9ePPNrWwx0zg2ttWp0Kyvvg HRm1qrUpIeUoEBj6QVt8uVD6q4isWJ83J2/WMUgQ8GWMqY1I22HXNDQd59R2glNI xLCkkpOc74QmGvGX00NA1an7VoveLQ+5gr53ZZ8iOLTfr92lmb+qjP9oyNBfJ5gI g6SINW5mzEzIGbPcqbkxm5aDe4RfVQrrdur+L+KkJtdWOwrhGrI3WW/8xoJxO6o7 AkjwhyD5M5+UVN9AmN3YmZpX9p0dJUtRymyNlGADwnJ+qUbQIu2OrsYvOy9ZJL/E CIsnAbMvelIGEIbFwXBN =Q/2Y -----END PGP SIGNATURE----- --HQLHrCACpVdwMl/9-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 17:58:17 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 036FE6F5; Sat, 11 Oct 2014 17:58:17 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC8E338; Sat, 11 Oct 2014 17:58:15 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id gm9so4906221lab.27 for ; Sat, 11 Oct 2014 10:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=k4aPXNhC9puvxX745aPjHytM9M3nuMibMpdbM6ns3Vo=; b=LKTAA4rcQL2O+pM+bR9ZtrwKQDzikqkT7dJuDyLqgkebiSm5xFl4MugHUwLQ9+lhqM PneTb06I32/F7No1of28HDkUAtg8s/CxVbtD7xVBI31PGeDZpZGsNdj8xABIYBez2cjK yK/SyJvLhii/nl4hswz4/TkvzKw28hGiE3hjq/PXR9So+dwdMhYdSlcpTqJUSBPlbU/S OLG6uJRUEAAVivMomxkvmYPDKYH3xXCcgljyDpHeH2Tb7DrLzJYCUpnOeRjk+FBydVUy UzxC5I6uV6tsZU5ImuygB8vjarOcKzW35bjBBDkVbQlsD/w1CuwtovjP75Cd/5gdAEdR n18w== MIME-Version: 1.0 X-Received: by 10.152.3.167 with SMTP id d7mr12815188lad.17.1413050293953; Sat, 11 Oct 2014 10:58:13 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Sat, 11 Oct 2014 10:58:13 -0700 (PDT) Date: Sat, 11 Oct 2014 10:58:13 -0700 X-Google-Sender-Auth: maglq4jH-2LPOPBwiqzx-dileUY Message-ID: Subject: Enabling VIMAGE by default for FreeBSD 11? From: Craig Rodrigues To: freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 17:58:17 -0000 Hi, What action items are left to enable VIMAGE by default for FreeBSD 11? Not everyone uses bhyve, so VIMAGE is quite useful when using jails. -- Craig From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 20:20:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9AEDC9A; Sat, 11 Oct 2014 20:20:34 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5CF6A2BA; Sat, 11 Oct 2014 20:20:34 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=[10.0.0.120]) by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xcz9s-000CZl-CW; Sat, 11 Oct 2014 20:04:40 +0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Enabling VIMAGE by default for FreeBSD 11? From: "Alexander V. Chernikov" In-Reply-To: Date: Sun, 12 Oct 2014 00:20:30 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-net@freebsd.org, "freebsd-virtualization@freebsd.org" , freebsd-arch X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 20:20:34 -0000 On 11 Oct 2014, at 21:58, Craig Rodrigues wrote: > Hi, >=20 > What action items are left to enable VIMAGE by default for FreeBSD 11? Are there any tests results showing performance implications on = different network-related workloads? >=20 > Not everyone uses bhyve, so VIMAGE is quite useful when using jails. >=20 > -- > Craig > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 22:03:14 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5EE2D8A9; Sat, 11 Oct 2014 22:03:14 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E44CDA4; Sat, 11 Oct 2014 22:03:14 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id uq10so6710041igb.1 for ; Sat, 11 Oct 2014 15:03:13 -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:message-id:subject :from:to:cc:content-type; bh=EXNRKj0VpgMh9vmepOGziF7IMB/zawxvsAJOfyjVzyk=; b=VTRJfLoOIrqsV/EuCYJE2OZLlSL4xre9Gy9GRGCJ/WsPH+4MvUvGa6KQlQgo6CYgUe p7D0/PPb8j4iUFfCpkjFCFG8rQg4qoAAkkORQlZ6BFKxKVFMe8Ie3WGOzxir9zMp/URd mQG8GibI+i6Wl1Bi+ilYt80wWO1OjE6OJNumGv79r0kWb2KFzTj0HRSy40UFGGUZpdzK 3LGbin/PucqAtRu4yG5prmePc1GwSYdmtcSHzzGfZQCdttsTVJ/IeIAszfPDiu0T1A1t d+WqM62/2IKmeaI4az3JuzD/G2wyOiJO+99Yhoep0D+frfqOtFXjovpS0tPMlTElCYu2 /d1Q== MIME-Version: 1.0 X-Received: by 10.50.72.3 with SMTP id z3mr18652436igu.36.1413064993387; Sat, 11 Oct 2014 15:03:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.50.78.4 with HTTP; Sat, 11 Oct 2014 15:03:13 -0700 (PDT) In-Reply-To: References: <20141001203223.GA12122@onelab2.iet.unipi.it> <20141001234926.GC13187@onelab2.iet.unipi.it> <20141001235312.GA14593@onelab2.iet.unipi.it> Date: Sat, 11 Oct 2014 15:03:13 -0700 X-Google-Sender-Auth: 0WOcaHfBmB3vNcVuRO8bnNtNOt4 Message-ID: Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 22:03:14 -0000 Ping, Luigi - would you mind sending through a diff ? I'd like to get this into -HEAD on both igb and ixgbe. Thanks! -a On 1 October 2014 16:53, Adrian Chadd wrote: > On 1 October 2014 16:53, Luigi Rizzo wrote: >> On Wed, Oct 01, 2014 at 04:47:32PM -0700, Adrian Chadd wrote: >>> On 1 October 2014 16:49, Luigi Rizzo wrote: >>> > On Wed, Oct 01, 2014 at 04:42:58PM -0700, Adrian Chadd wrote: >>> >> Yeah, just grab the diffs that I committed to ixgbe and try it out. >>> >> >>> >> The flowdirector initialisation is buggy. :) >>> > >>> > ok but i don't think it is related, see my previous email. >>> >>> I saw - but the verisign people also saw queue stalls as well. >>> >>> So is setting DROP_EN unconditionally fixing it for you? >> >> yes so it seems. > > Interesting. That's a pretty small window to get it wrong in. > > Would you file a PR about it? We'll try to get this fixed soon. > > (Same for igb..) > > Thanks! > > > > -a From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 22:21:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D5C24F0; Sat, 11 Oct 2014 22:21:33 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 56667EF6; Sat, 11 Oct 2014 22:21:32 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BDE197300B; Sun, 12 Oct 2014 00:24:57 +0200 (CEST) Date: Sun, 12 Oct 2014 00:24:57 +0200 From: Luigi Rizzo To: Adrian Chadd Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) Message-ID: <20141011222457.GA11694@onelab2.iet.unipi.it> References: <20141001203223.GA12122@onelab2.iet.unipi.it> <20141001234926.GC13187@onelab2.iet.unipi.it> <20141001235312.GA14593@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 22:21:33 -0000 On Sat, Oct 11, 2014 at 03:03:13PM -0700, Adrian Chadd wrote: > Ping, > > Luigi - would you mind sending through a diff ? I'd like to get this > into -HEAD on both igb and ixgbe. here it is. As a result of this patch, ixgbe_rx_enable_drop() and the disable function become useless and should be removed. Probably the code (or the commit log) should also mention that the DROP_EN bit is only read when the rx unit is started, this is why the code should go here and not in the sysctl handler. cheers luigi Index: ixgbe.c =================================================================== --- ixgbe.c (revision 272603) +++ ixgbe.c (working copy) @@ -4377,6 +4377,19 @@ srrctl &= ~IXGBE_SRRCTL_BSIZEPKT_MASK; srrctl |= bufsz; srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF; + /* + * Set DROP_EN iff we have no flow control and >1 queue. + * Note that srrctl was cleared shortly before during reset, + * so we do not need to clear the bit, but do it just in case + * this code is moved elsewhere. + */ + if (adapter->num_queues > 1 && + adapter->hw.fc.requested_mode == ixgbe_fc_none) { + srrctl |= IXGBE_SRRCTL_DROP_EN; + } else { + srrctl &= ~IXGBE_SRRCTL_DROP_EN; + } + IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(i), srrctl); /* Setup the HW Rx Head and Tail Descriptor Pointers */ From owner-freebsd-net@FreeBSD.ORG Sat Oct 11 22:40:43 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C35077C; Sat, 11 Oct 2014 22:40:43 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8959F111; Sat, 11 Oct 2014 22:40:42 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id fb4so4748066wid.12 for ; Sat, 11 Oct 2014 15:40:39 -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:message-id:subject :from:to:cc:content-type; bh=Bcqy9GbiBNQs3yt6slbPZQD9CiwLIgdporz40LMhTfs=; b=xrcV0DB1lVvPqNhxneMN/Ff9E6lXi7NLI6rbP6BHZ8KaSPipTryya9Ex/w/1OYQBa7 3u/YhdW2YPHnVnhWEhVqFQvy61uGBRBblCS7jaWgfEslcjQya7b6+UvQPInRhUb3gtYH h/VA5yYCIDiXNgTCL3ouFxV5cJ5c4PILQxCV6me9PxES6rJ6NkLwExhqXo2aC+pxagan y740F3JU5sDZ8Ik2ebGTkJsuuQRtywYnP0o56AhISR9LYjZsq60mltzl+tuHYhUuLHoW /wgx/n7tr/6ieO1GS9AtgvkLPmpsm+cMtyn4mnQmr3w7dYVLE0iC2cj3m4du9gEpAFc6 LSBA== MIME-Version: 1.0 X-Received: by 10.180.107.100 with SMTP id hb4mr11760244wib.59.1413067239475; Sat, 11 Oct 2014 15:40:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 11 Oct 2014 15:40:39 -0700 (PDT) In-Reply-To: <20141011222457.GA11694@onelab2.iet.unipi.it> References: <20141001203223.GA12122@onelab2.iet.unipi.it> <20141001234926.GC13187@onelab2.iet.unipi.it> <20141001235312.GA14593@onelab2.iet.unipi.it> <20141011222457.GA11694@onelab2.iet.unipi.it> Date: Sat, 11 Oct 2014 15:40:39 -0700 X-Google-Sender-Auth: dIyVT6h7xbroB6Hdq7cISbCDDxY Message-ID: Subject: Re: individual queue blocking entire rx unit on ixgbe (Re: How do I balance bandwidth over several virtual NICs?) From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" , Elof Ofel , "Alexander V. Chernikov" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 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, 11 Oct 2014 22:40:43 -0000 Thanks! I'll review/commit this to -HEAD now. -a On 11 October 2014 15:24, Luigi Rizzo wrote: > On Sat, Oct 11, 2014 at 03:03:13PM -0700, Adrian Chadd wrote: >> Ping, >> >> Luigi - would you mind sending through a diff ? I'd like to get this >> into -HEAD on both igb and ixgbe. > > > here it is. > > As a result of this patch, ixgbe_rx_enable_drop() and the disable function > become useless and should be removed. > Probably the code (or the commit log) should also mention that the DROP_EN > bit is only read when the rx unit is started, this is why the code should > go here and not in the sysctl handler. > > cheers > luigi > > Index: ixgbe.c > =================================================================== > --- ixgbe.c (revision 272603) > +++ ixgbe.c (working copy) > @@ -4377,6 +4377,19 @@ > srrctl &= ~IXGBE_SRRCTL_BSIZEPKT_MASK; > srrctl |= bufsz; > srrctl |= IXGBE_SRRCTL_DESCTYPE_ADV_ONEBUF; > + /* > + * Set DROP_EN iff we have no flow control and >1 queue. > + * Note that srrctl was cleared shortly before during reset, > + * so we do not need to clear the bit, but do it just in case > + * this code is moved elsewhere. > + */ > + if (adapter->num_queues > 1 && > + adapter->hw.fc.requested_mode == ixgbe_fc_none) { > + srrctl |= IXGBE_SRRCTL_DROP_EN; > + } else { > + srrctl &= ~IXGBE_SRRCTL_DROP_EN; > + } > + > IXGBE_WRITE_REG(hw, IXGBE_SRRCTL(i), srrctl); > > /* Setup the HW Rx Head and Tail Descriptor Pointers */