From owner-freebsd-net@freebsd.org Sun Sep 4 21:00:19 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 692DBB7169C for ; Sun, 4 Sep 2016 21:00:19 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) 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 6022E7B1 for ; Sun, 4 Sep 2016 21:00:19 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u84L01qF021693 for ; Sun, 4 Sep 2016 21:00:19 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201609042100.u84L01qF021693@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 Date: Sun, 04 Sep 2016 21:00:19 +0000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 04 Sep 2016 21:00:19 -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 ------------+-----------+--------------------------------------------------- In Progress | 203422 | mpd/ppoe not working with re(4) with revision 285 In Progress | 206581 | bxe_ioctl_nvram handler is faulty New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 205592 | TCP processing in IPSec causes kernel panic New | 206053 | kqueue support code of netmap causes panic Open | 148807 | [panic] "panic: sbdrop" and "panic: sbsndptr: soc Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 194485 | Userland cannot add IPv6 prefix routes Open | 194515 | Fatal Trap 12 Kernel with vimage Open | 199136 | [if_tap] Added down_on_close sysctl variable to t Open | 206544 | sendmsg(2) (sendto(2) too?) can fail with EINVAL; Open | 211031 | [panic] in ng_uncallout when argument is NULL Open | 211962 | bxe driver queue soft hangs and flooding tx_soft_ 13 problems total for which you should take action. From owner-freebsd-net@freebsd.org Mon Sep 5 12:42:34 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC172A9D3FD for ; Mon, 5 Sep 2016 12:42:34 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F701E8E for ; Mon, 5 Sep 2016 12:42:34 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x22a.google.com with SMTP id i184so144477593itf.1 for ; Mon, 05 Sep 2016 05:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=Z8rsFxQItYuGWaoNoQKAqO5dxhPMfFpp6Q6NBR9GccU=; b=NA2tfzp21nLnIfsevEyuMeZw4QWe7k5sS/FcyLohChA91OhgO7XsZyWd83XrFoxmH6 VGM78RvLY2ehMtogJnHAxlgmVlOLZrLOP1POsmAAYcg9uwVqb7ix6A+QACZ1CLw2SYXo z5mZsrrvM09TNNez7g7FebRDsg6Eg7yuCo7awOgC+MkwvwY+xAw1LamS86l3HI+PZr7Q XU1s6HPPRCe3Eq+TFlYoxc5GWSZmooTcCiUmBG6kKOzB96UjT1Ncoqmd7VztmY4PPgA5 FKbi3F+bqf/+XPuOXQU7VpZX5MGOxaDKJ1ZRZQb34lSjOuihIw/yWVtLmhWgezeJhu3O 4LYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Z8rsFxQItYuGWaoNoQKAqO5dxhPMfFpp6Q6NBR9GccU=; b=SY3QukGzirHu08RPYbhTWZCuQ1LSUrBVK2FQlS6HXoOKeRm2BcqDyutoBYSsFMyA3V bCVuzuPnFPziZ5KtKEg69nj7IdTRg5QPj0old9gTO/o/cx/3SUTz/s57V7usYLKdefdm TW9Aba42wnV1mMXVDdGEPMwCLaBuaK+XXeWg1BGynxOlJWO9VrgPC3z/wb9X4Q0JXqdo TE2In45Q3P+0886UmCUPS05BuPGcRtpCd89s/y2/joVMkVQt98RWEO4bkqe4WkAAqCDu 6pZmae9NhVoObUmIz80fCEnsgeqNwZKpe4CEW/UL+veJddUi+COXhgW1EwsFJ8Q0mTDA 85kw== X-Gm-Message-State: AE9vXwO13LTUfzAUl4gk+Snzq00E9pYf3m1XM8aKsgzmmcGCNy9gQgpWYpqx5o4IL+NdWJA2qYBEt8PdJBff2464 X-Received: by 10.36.190.75 with SMTP id i72mr24905634itf.92.1473079353750; Mon, 05 Sep 2016 05:42:33 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.149.196 with HTTP; Mon, 5 Sep 2016 05:42:33 -0700 (PDT) From: Maxim Sobolev Date: Mon, 5 Sep 2016 05:42:33 -0700 X-Google-Sender-Auth: -21eCBwmnteKcHNtlhC1YwtC6l8 Message-ID: Subject: Which UDP sockets the incoming packet is delivered to when both wildcard and non-wildcard listeners are present To: FreeBSD Net , Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Sep 2016 12:42:34 -0000 Hi Netters, Suppose we have two threads in the system both bound to a same specific UDP port, one using INADDR_ANY and another one using actual IP. When incoming message arrives to that port is there any guarantee as to which of those two threads going to see the message? The question has arisen from the observation that most of the time the thread that is bound to a specific IP gets them, but occasionally we see INADDR_ANY-bound thread receiving few packets as well. So that behavior seems to be "almost deterministic" and we are wondering where that "almost" part is expected or some kind of socket matching bug? OS in question is 10.3-RELEASE-p5 [ssp-root@dal23 ~]$ sockstat | grep 24421 | grep udp4 | grep -w 5071 b2bua python2.7 24421 7 udp4 *:5071 *:* b2bua python2.7 24421 58 udp4 X.Y.Z.W:5071 *:* I apologize if this is answered somewhere already, any pointers would be appreciated. Thanks! -Max From owner-freebsd-net@freebsd.org Mon Sep 5 12:47:23 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E910CA9D4D4 for ; Mon, 5 Sep 2016 12:47:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7DD6FEB for ; Mon, 5 Sep 2016 12:47:23 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-it0-x22a.google.com with SMTP id e124so144728979ith.0 for ; Mon, 05 Sep 2016 05:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=q9LOcecAId2BjcJxQOr9nUPICxWNbs3g8Q7tLxp8A48=; b=xnZhayGe7ZBEbGtnX2FLkAlrOU7Z8X3BdWxvCGBGTzekKu0N0qnPE3aeVv/OKywDu+ q6IuH8d/NSxO5BZwbW0ZjZKwxhF5t3V1S6vP4W541LbIzTRZcNEo+lcPXNAXbRtDXi2f tvXxtB3++g+ceuDWjF+/XhAFtQH4Thn6H/wrY1iuL1aqexgEqM/Cg9DRZWWPKboCCCWu cHRqFnS7ABx49+HjJd08lCJ9YgfHOCTrXFvu0dSJsLQaKf0DRObWNY0Wqr8jrD9FOg58 poN7jdejyewJOCAeRD9i53DAXUI9MNETllDlPsW1mxSDEyCKh49xeCU7vwB5uojV/gpu S40Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=q9LOcecAId2BjcJxQOr9nUPICxWNbs3g8Q7tLxp8A48=; b=Yc+auy5z4WgU+s+dxT4OphvH9Uq7xv44z/S6tPQP5xWJ9Zh66HxVg5P8yb4XDaRiy6 XYRWAV0gu/7+Hr0oM3jUyjuET9NBMB/FeigahLbEsR2aAKL1kqBE32zMPKWSeGM0wNiP xBXaN8TZo6HXsZFt1P0fI3IpSWyo2Wz/DNzC2e8iFFau++OP00r9rcjEJSChXczb0q2x Vaow9jrQBy9urMyOXYm4amhn+vRe10bBgjz/I1AyS54Gatuc7IhKlC41lWNAFUr1Bf02 d18CsbqDrkso7hYc5ZEVzgqfXrF6/cPIyypueARFx9KuCbGVEMAAgy55QEv2WSF/3AhY BZEQ== X-Gm-Message-State: AE9vXwNTOoCkbMUWfb0/IZ3SvhX4nIkipfADKRux2tm21mPC7iXkT47pzh/YnIda5W/pmagYFVVzUXeRhVignuIp X-Received: by 10.36.209.130 with SMTP id w124mr25100933itg.2.1473079643098; Mon, 05 Sep 2016 05:47:23 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.149.196 with HTTP; Mon, 5 Sep 2016 05:47:22 -0700 (PDT) In-Reply-To: References: From: Maxim Sobolev Date: Mon, 5 Sep 2016 05:47:22 -0700 X-Google-Sender-Auth: 8GQI_9Ubr61_nWylh6WWs1tbYHs Message-ID: Subject: Re: Which UDP sockets the incoming packet is delivered to when both wildcard and non-wildcard listeners are present To: FreeBSD Net , Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Sep 2016 12:47:24 -0000 P.S. Destination UDP address of the message in question is obviously X.Y.Z.W:5071. On Mon, Sep 5, 2016 at 5:42 AM, Maxim Sobolev wrote: > Hi Netters, > > Suppose we have two threads in the system both bound to a same specific > UDP port, one using INADDR_ANY and another one using actual IP. When > incoming message arrives to that port is there any guarantee as to which of > those two threads going to see the message? The question has arisen from > the observation that most of the time the thread that is bound to a > specific IP gets them, but occasionally we see INADDR_ANY-bound thread > receiving few packets as well. So that behavior seems to be "almost > deterministic" and we are wondering where that "almost" part is expected or > some kind of socket matching bug? > > OS in question is 10.3-RELEASE-p5 > > [ssp-root@dal23 ~]$ sockstat | grep 24421 | grep udp4 | grep -w 5071 > b2bua python2.7 24421 7 udp4 *:5071 *:* > b2bua python2.7 24421 58 udp4 X.Y.Z.W:5071 *:* > > I apologize if this is answered somewhere already, any pointers would be > appreciated. Thanks! > > -Max > From owner-freebsd-net@freebsd.org Mon Sep 5 13:48:21 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 487C4B964AD for ; Mon, 5 Sep 2016 13:48:21 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4j.cmail.yandex.net (forward4j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C262CF9B; Mon, 5 Sep 2016 13:48:20 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp1p.mail.yandex.net (smtp1p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b6:6]) by forward4j.cmail.yandex.net (Yandex) with ESMTP id DFE2320DF2; Mon, 5 Sep 2016 16:48:17 +0300 (MSK) Received: from smtp1p.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1p.mail.yandex.net (Yandex) with ESMTP id C4A691780986; Mon, 5 Sep 2016 16:48:16 +0300 (MSK) Received: by smtp1p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 41exwgjcnA-mFwq3nCq; Mon, 05 Sep 2016 16:48:15 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1473083295; bh=rByx1X6jwtLzrQW1NAD3XYNhp1oOXbggGlZXX6YNl58=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=qcnO1uldSqtahySOyWiUrpxW3E7/drI1PfeUWBXeucEosnh9AI13Hw7gt0wvLkr18 OD6ArT6uG/LfkLhGPDZgVXy7T9lrKhnB9CPj2olSAo2p6um0D/+edVDfngNGhGOvUe Kt9Utz2RSlSJqu5dvb1hNK2jSO337sSc0VIuXia8= Authentication-Results: smtp1p.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0 Subject: Re: Which UDP sockets the incoming packet is delivered to when both wildcard and non-wildcard listeners are present To: Maxim Sobolev , FreeBSD Net , Gleb Smirnoff References: From: "Andrey V. Elsukov" Message-ID: Date: Mon, 5 Sep 2016 16:46:17 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5VbiFm0ebbL8ttbXHxreUOtTE0A4A0FRI" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 05 Sep 2016 13:48:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5VbiFm0ebbL8ttbXHxreUOtTE0A4A0FRI Content-Type: multipart/mixed; boundary="vxhEb7ONWc6MIuvqeOsEVuQstACl9ujL9" From: "Andrey V. Elsukov" To: Maxim Sobolev , FreeBSD Net , Gleb Smirnoff Message-ID: Subject: Re: Which UDP sockets the incoming packet is delivered to when both wildcard and non-wildcard listeners are present References: In-Reply-To: --vxhEb7ONWc6MIuvqeOsEVuQstACl9ujL9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 05.09.16 15:42, Maxim Sobolev wrote: > Suppose we have two threads in the system both bound to a same specific= UDP > port, one using INADDR_ANY and another one using actual IP. When incomi= ng > message arrives to that port is there any guarantee as to which of thos= e > two threads going to see the message? The question has arisen from the > observation that most of the time the thread that is bound to a specifi= c IP > gets them, but occasionally we see INADDR_ANY-bound thread receiving fe= w > packets as well. So that behavior seems to be "almost deterministic" an= d we > are wondering where that "almost" part is expected or some kind of sock= et > matching bug? Are your sockets connected? I.e. did you use connect+send? And do you receive unicast datagrams or some broadcast/multicast can appear? --=20 WBR, Andrey V. Elsukov --vxhEb7ONWc6MIuvqeOsEVuQstACl9ujL9-- --5VbiFm0ebbL8ttbXHxreUOtTE0A4A0FRI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEvBAEBCAAZBQJXzXctEhxidTdjaGVyQHlhbmRleC5ydQAKCRABxeoEEMihetDJ B/wNrwZlItx9l6jG6CbCsrSXor4TjNgf+WCAAb8tBSHvL38mWEUKuQCJ3pHBMbRT PEe+iNa3rrBc0DO/Q4DfLG333iBmMeNbwXZUMPQ6Bx4BWJh929c7uAPdWcRxR4IP 1dgpqck6YJ+N2z/yQLatNb3it2kOgKkjX9qrncSeCBakeWTm7wdOP5ViVBPPG0XG emVxd6oED3parfyPm8QMqdJ+RSW0TojKc7A3HV/wNuYIRmJtjRJyFf4yFiZBufgJ /C762EnYk6PcaLN83h8Ok+QDSUeRd7k1c33TMB75bjAA3iusII3qJla3e1bd/lMj Uzc8vhG8SUkx0asQFaK6hQAt =gq2O -----END PGP SIGNATURE----- --5VbiFm0ebbL8ttbXHxreUOtTE0A4A0FRI-- From owner-freebsd-net@freebsd.org Mon Sep 5 14:26:55 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C9BDB960B8 for ; Mon, 5 Sep 2016 14:26:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 1BE4B1457 for ; Mon, 5 Sep 2016 14:26:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u85EQsx7006292 for ; Mon, 5 Sep 2016 14:26:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 212283] network watchdog timeout with some raw sockets usage Date: Mon, 05 Sep 2016 14:26:54 +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: 11.0-RC1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: mat@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 05 Sep 2016 14:26:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212283 --- Comment #10 from Mathieu Arnold --- I can't test a kernel patch on both boxes I have that currently run 11.0-RC= 2. I can try to find the time to install something like vmware on my mac to install a FreeBSD to test this patch, but I don't see this happening this w= eek or the next. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Sep 6 07:03:30 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 344FFB961CC for ; Tue, 6 Sep 2016 07:03:30 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E72A37F2 for ; Tue, 6 Sep 2016 07:03:29 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x231.google.com with SMTP id w78so83994618oie.3 for ; Tue, 06 Sep 2016 00:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ORohFv63ZxhRYRNcxNjlbBqdTlD1eM5U06i2uDoJsmQ=; b=Vdbyl5a6JN1VbCoILlRA/+Clsb5yRNP29MplJeXs0yXNFUUUcZSTByUsGZSYtrjVup fVbcXML7naCjku83yiYrfAaZHAtt+NbDhQxgPEoJqSjwS62uNMJI/eX6pxGOiIFDQvtI PcWz/svQ37/GEA8DVHPvcpMxvnmhWF8glEXJcEz2qFD0we/YWFTy7HNqVrln2uSyO2fn vw+TE3/J2B0NqaMCaOeZOYubfaS5Ddec2wr0aq8N6u3YSvvTRslJCfR7RvdYL1FbHXhK CgVPfisJ6vM5Zuiy5n35xzhvFTMQxQTN7E1lHQpG9V3QSNdPXcNBHfD3MdsXIux+k6nP 6UqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ORohFv63ZxhRYRNcxNjlbBqdTlD1eM5U06i2uDoJsmQ=; b=fV6Tr/GcAMBzWvDs2MFdn0U144cjcVQWrUlHwmum5sC5KIQw03Y3fDX4644A/ODGS/ p6S3rGCYBOSl+GOjBI19i+Ww60ZrA+jWOXrgPJ8thyRJJWuHPeAMX00PWDulHYfNJNLL Yspr+YUzsJ5GAFtaI7yKldu+2xlVqA6Fptg7Kor/WaG/Lb4DKnKAYbB1fsRouwA4yrK6 29MPgHugDAEpwCwOZ2P5tdC6f9rYrpOP0HbHNJC/UNI+WAa8dBfXWzw3N2os0yl9eDH7 7o/+LbrqYDVEuzRsDpHZg/Inj6+IsOWZ9NiN8jI5YtjWfbozhpCUDRrhyFu3TH5tal1x 91fg== X-Gm-Message-State: AE9vXwMMrNWXuAPkvsrgoBJBa9fwrLY7gPjlA8qPWy6PHBUvIbp7J806ga1/i0EdimeOjMA6JNobAijjqO8xrgMX X-Received: by 10.107.55.194 with SMTP id e185mr3572432ioa.34.1473145408239; Tue, 06 Sep 2016 00:03:28 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.149.196 with HTTP; Tue, 6 Sep 2016 00:03:27 -0700 (PDT) In-Reply-To: References: From: Maxim Sobolev Date: Tue, 6 Sep 2016 00:03:27 -0700 X-Google-Sender-Auth: CUQLA0xx8jY9Wt08QN1hRPBkMx8 Message-ID: Subject: Re: Which UDP sockets the incoming packet is delivered to when both wildcard and non-wildcard listeners are present To: "Andrey V. Elsukov" Cc: FreeBSD Net , Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Sep 2016 07:03:30 -0000 Andrey, 1. Sockets are unconnected 2. Datagrams are unicast -Max On Mon, Sep 5, 2016 at 6:46 AM, Andrey V. Elsukov wrote: > On 05.09.16 15:42, Maxim Sobolev wrote: > > Suppose we have two threads in the system both bound to a same specific > UDP > > port, one using INADDR_ANY and another one using actual IP. When incoming > > message arrives to that port is there any guarantee as to which of those > > two threads going to see the message? The question has arisen from the > > observation that most of the time the thread that is bound to a specific > IP > > gets them, but occasionally we see INADDR_ANY-bound thread receiving few > > packets as well. So that behavior seems to be "almost deterministic" and > we > > are wondering where that "almost" part is expected or some kind of socket > > matching bug? > > Are your sockets connected? I.e. did you use connect+send? And do you > receive unicast datagrams or some broadcast/multicast can appear? > > -- > WBR, Andrey V. Elsukov > > From owner-freebsd-net@freebsd.org Tue Sep 6 08:22:28 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97298A9D394 for ; Tue, 6 Sep 2016 08:22:28 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44AC87FB for ; Tue, 6 Sep 2016 08:22:27 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.106] (vpn01-01.tdx.co.uk [62.13.130.213] (may be forged)) (authenticated bits=0) by smtp.krpservers.com (8.15.2/8.15.2) with ESMTPSA id u868Ddtf030546 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Sep 2016 09:13:40 +0100 (BST) (envelope-from kpielorz_lst@tdx.co.uk) Date: Tue, 06 Sep 2016 09:13:28 +0100 From: Karl Pielorz To: freebsd-net@FreeBSD.org Subject: lagg Interfaces - don't do Gratuitous ARP? Message-ID: <0D84203FAAFD0A8E7BBB24A3@[10.12.30.106]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Sep 2016 08:22:28 -0000 Hi, We've just changed the network config on a box - going from a single 'em1' adapter to a lagg failover of em0, em1. This works - but we noticed after the machine rebooted, we couldn't ping it from other hosts. Checking on other machines on the LAN they still had an ARP entry for the changed hosts old em1's MAC. On the lagg machine - the MAC used for the NIC's (and lagg) was now the MAC for em0 (which I believe is correct behaviour). Should the act of lagg / IP's coming up not send a gratuitous ARP for them or something to avoid this? As it was we had to log into a number of key boxes and 'arp -d' the IP's - and take a ~800 second 'hit' on other boxes timing out the old MAC. -Karl From owner-freebsd-net@freebsd.org Tue Sep 6 08:42:59 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C232BA9DEDF for ; Tue, 6 Sep 2016 08:42:59 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52BD12A5 for ; Tue, 6 Sep 2016 08:42:59 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x236.google.com with SMTP id w12so78145509wmf.0 for ; Tue, 06 Sep 2016 01:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=xnocjiTe+LftgyCEomqX5XjNpHdGxvG0VKjVnj5+5eM=; b=iyNX10B0reS2fv4rUWAJBvxdEZj98xqmG5m4OaAweSgyBSEaVOEiJ7S9Re5JoOe4pT d/F3tuxDXGj+cU+QrtnhTMSecbsIV/CnZjqaABGrBOjwe3TE1PKVSTGaV8CruQOdJhmf QaXZ/D4sFcOCetoenprncI04Y0p8Csys4HjCHgOjtcGNl+4AyvIh1MBnvV6crxYL5IvM W53WGGDe3a3UTTg4ImieDvLYUf67UR2eYcPHFG9aJBLMOzLRErzT3wWWPylSMuRrRFQz FpuUCmLXYWE9GwoAyUdDDZdTutOHm9Ntb3ASYctaCSSBwi4ErW0eef/8ekzayZg3KzWC v9pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xnocjiTe+LftgyCEomqX5XjNpHdGxvG0VKjVnj5+5eM=; b=ZSpgCRTykQWnpEnEUNN7VQjyhrdXsehIhvTMX7uL/R0gnRD/Jn0M3aPARYIFVHZQQN 2gjOZihKGh42YhlMXMGN7nEwA8YM0ZNk3Wf9zVfHiX0x3ubzRpDkVRh6IbJKLWjFKLGr 8z13GFC5As/N/IkieHL66SQqOGnEnJZ5NnxtNty/0CO3oHbzhu2TFVoftVgrk3b+dKT5 jTDF/YrY8Edr2QuFgoxDw8/Eu2c2ukKSh2pL0PEoCr1xOBtuV622ZevQ9pzzrytmvB2U /bti44cCNLlCadv6amV1aWB1ckVvUaVr1PvR5j8/O0ry4zOnbBugwp9NTVliCzDq203V ec4g== X-Gm-Message-State: AE9vXwNjzy5LwuKpWOMs5vuV4gvughQCxVTLRmOE8LXDpldzHQqK2opUBZoYGhNDtz80w2Ow X-Received: by 10.194.243.8 with SMTP id wu8mr34109221wjc.178.1473151377218; Tue, 06 Sep 2016 01:42:57 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id w203sm25151290wmw.7.2016.09.06.01.42.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Sep 2016 01:42:56 -0700 (PDT) Subject: Re: lagg Interfaces - don't do Gratuitous ARP? To: freebsd-net@freebsd.org References: <0D84203FAAFD0A8E7BBB24A3@[10.12.30.106]> From: Steven Hartland Message-ID: Date: Tue, 6 Sep 2016 09:42:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <0D84203FAAFD0A8E7BBB24A3@[10.12.30.106]> Content-Type: multipart/mixed; boundary="------------8DA201AA1DCCAD657B20F1BD" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Sep 2016 08:42:59 -0000 This is a multi-part message in MIME format. --------------8DA201AA1DCCAD657B20F1BD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Yes known issue I'm afraid. I created a patch set to address this but there where objections so it was removed, see the attached which is based on 10.2-RELEASE. On 06/09/2016 09:13, Karl Pielorz wrote: > > Hi, > > We've just changed the network config on a box - going from a single > 'em1' adapter to a lagg failover of em0, em1. > > This works - but we noticed after the machine rebooted, we couldn't > ping it from other hosts. > > Checking on other machines on the LAN they still had an ARP entry for > the changed hosts old em1's MAC. > > On the lagg machine - the MAC used for the NIC's (and lagg) was now > the MAC for em0 (which I believe is correct behaviour). > > Should the act of lagg / IP's coming up not send a gratuitous ARP for > them or something to avoid this? > > As it was we had to log into a number of key boxes and 'arp -d' the > IP's - and take a ~800 second 'hit' on other boxes timing out the old > MAC. > > > -Karl > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --------------8DA201AA1DCCAD657B20F1BD Content-Type: text/plain; charset=UTF-8; name="lagg-arp02-link.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lagg-arp02-link.patch" Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 291071) +++ sys/net/if.c (working copy) @@ -126,7 +126,7 @@ SX_SYSINIT(ifdescr_sx, &ifdescr_sx, "ifnet descr") void (*bridge_linkstate_p)(struct ifnet *ifp); void (*ng_ether_link_state_p)(struct ifnet *ifp, int state); -void (*lagg_linkstate_p)(struct ifnet *ifp, int state); +void (*lagg_linkstate_p)(struct ifnet *ifp); /* These are external hooks for CARP. */ void (*carp_linkstate_p)(struct ifnet *ifp); void (*carp_demote_adj_p)(int, char *); @@ -1980,6 +1980,8 @@ if_unroute(struct ifnet *ifp, int flag, int fam) if (ifp->if_carp) (*carp_linkstate_p)(ifp); + if (ifp->if_lagg) + (*lagg_linkstate_p)(ifp); rt_ifmsg(ifp); } @@ -2001,6 +2003,8 @@ if_route(struct ifnet *ifp, int flag, int fam) pfctlinput(PRC_IFUP, ifa->ifa_addr); if (ifp->if_carp) (*carp_linkstate_p)(ifp); + if (ifp->if_lagg) + (*lagg_linkstate_p)(ifp); rt_ifmsg(ifp); #ifdef INET6 in6_if_up(ifp); @@ -2015,17 +2019,27 @@ int (*vlan_tag_p)(struct ifnet *, uint16_t *); int (*vlan_setcookie_p)(struct ifnet *, void *); void *(*vlan_cookie_p)(struct ifnet *); +void +if_link_state_change(struct ifnet *ifp, int link_state) +{ + + return if_link_state_change_cond(ifp, link_state, 0); +} + /* * Handle a change in the interface link state. To avoid LORs * between driver lock and upper layer locks, as well as possible * recursions, we post event to taskqueue, and all job * is done in static do_link_state_change(). + * + * If the current link state matches link_state and force isn't + * specified no action is taken. */ void -if_link_state_change(struct ifnet *ifp, int link_state) +if_link_state_change_cond(struct ifnet *ifp, int link_state, int force) { - /* Return if state hasn't changed. */ - if (ifp->if_link_state == link_state) + + if (ifp->if_link_state == link_state && !force) return; ifp->if_link_state = link_state; @@ -2053,7 +2067,7 @@ do_link_state_change(void *arg, int pending) if (ifp->if_bridge) (*bridge_linkstate_p)(ifp); if (ifp->if_lagg) - (*lagg_linkstate_p)(ifp, link_state); + (*lagg_linkstate_p)(ifp); if (IS_DEFAULT_VNET(curvnet)) devctl_notify("IFNET", ifp->if_xname, Index: sys/net/if_lagg.c =================================================================== --- sys/net/if_lagg.c (revision 291071) +++ sys/net/if_lagg.c (working copy) @@ -106,7 +106,7 @@ static int lagg_port_create(struct lagg_softc *, s static int lagg_port_destroy(struct lagg_port *, int); static struct mbuf *lagg_input(struct ifnet *, struct mbuf *); static void lagg_linkstate(struct lagg_softc *); -static void lagg_port_state(struct ifnet *, int); +static void lagg_port_state(struct ifnet *); static int lagg_port_ioctl(struct ifnet *, u_long, caddr_t); static int lagg_port_output(struct ifnet *, struct mbuf *, const struct sockaddr *, struct route *); @@ -1774,8 +1774,13 @@ lagg_linkstate(struct lagg_softc *sc) break; } } - if_link_state_change(sc->sc_ifp, new_link); + /* + * Force state change to ensure ifnet_link_event is generated allowing + * protocols to notify other nodes of potential address move. + */ + if_link_state_change_cond(sc->sc_ifp, new_link, 1); + /* Update if_baudrate to reflect the max possible speed */ switch (sc->sc_proto) { case LAGG_PROTO_FAILOVER: @@ -1797,7 +1802,7 @@ lagg_linkstate(struct lagg_softc *sc) } static void -lagg_port_state(struct ifnet *ifp, int state) +lagg_port_state(struct ifnet *ifp) { struct lagg_port *lp = (struct lagg_port *)ifp->if_lagg; struct lagg_softc *sc = NULL; @@ -1813,7 +1818,7 @@ static void LAGG_WUNLOCK(sc); } -struct lagg_port * +static struct lagg_port * lagg_link_active(struct lagg_softc *sc, struct lagg_port *lp) { struct lagg_port *lp_next, *rval = NULL; Index: sys/net/if_lagg.h =================================================================== --- sys/net/if_lagg.h (revision 291071) +++ sys/net/if_lagg.h (working copy) @@ -281,7 +281,7 @@ struct lagg_port { #define LAGG_UNLOCK_ASSERT(_sc) rm_assert(&(_sc)->sc_mtx, RA_UNLOCKED) extern struct mbuf *(*lagg_input_p)(struct ifnet *, struct mbuf *); -extern void (*lagg_linkstate_p)(struct ifnet *, int ); +extern void (*lagg_linkstate_p)(struct ifnet *); int lagg_enqueue(struct ifnet *, struct mbuf *); Index: sys/net/if_var.h =================================================================== --- sys/net/if_var.h (revision 291071) +++ sys/net/if_var.h (working copy) @@ -962,6 +962,7 @@ struct ifmultiaddr * void if_free(struct ifnet *); void if_initname(struct ifnet *, const char *, int); void if_link_state_change(struct ifnet *, int); +void if_link_state_change_cond(struct ifnet *, int, int); int if_printf(struct ifnet *, const char *, ...) __printflike(2, 3); void if_qflush(struct ifnet *); void if_ref(struct ifnet *); Index: sys/netinet/if_ether.c =================================================================== --- sys/netinet/if_ether.c (revision 291071) +++ sys/netinet/if_ether.c (working copy) @@ -97,12 +97,14 @@ VNET_PCPUSTAT_SYSUNINIT(arpstat); #endif /* VIMAGE */ static VNET_DEFINE(int, arp_maxhold) = 1; +static VNET_DEFINE(int, arp_on_link) = 1; #define V_arpt_keep VNET(arpt_keep) #define V_arpt_down VNET(arpt_down) #define V_arp_maxtries VNET(arp_maxtries) #define V_arp_proxyall VNET(arp_proxyall) #define V_arp_maxhold VNET(arp_maxhold) +#define V_arp_on_link VNET(arp_on_link) SYSCTL_VNET_INT(_net_link_ether_inet, OID_AUTO, max_age, CTLFLAG_RW, &VNET_NAME(arpt_keep), 0, @@ -135,6 +137,7 @@ static void in_arpinput(struct mbuf *); static void arp_iflladdr(void *arg __unused, struct ifnet *ifp); static eventhandler_tag iflladdr_tag; +static eventhandler_tag ifnet_link_event_tag; static const struct netisr_handler arp_nh = { .nh_name = "arp", @@ -559,6 +562,9 @@ SYSCTL_INT(_net_link_ether_inet, OID_AUT CTLFLAG_RW, &arp_maxpps, 0, "Maximum number of remotely triggered ARP messages that can be " "logged per second"); +SYSCTL_INT(_net_link_ether_inet, OID_AUTO, arp_on_link, CTLFLAG_VNET | CTLFLAG_RW, + &VNET_NAME(arp_on_link), 0, + "Send gratuitous ARP's on interface link up events"); #define ARP_LOG(pri, ...) do { \ if (ppsratecheck(&arp_lastlog, &arp_curpps, arp_maxpps)) \ @@ -972,7 +978,7 @@ arp_ifinit(struct ifnet *ifp, struct ifa if (ntohl(dst_in->sin_addr.s_addr) == INADDR_ANY) return; - arp_announce_ifaddr(ifp, dst_in->sin_addr, IF_LLADDR(ifp)); + arp_announce_addr(ifp, &dst_in->sin_addr, IF_LLADDR(ifp)); /* * interface address is considered static entry @@ -972,38 +978,91 @@ arp_ifinit(struct ifnet *ifp, struct ifa ifa->ifa_rtrequest = NULL; } -void -arp_announce_ifaddr(struct ifnet *ifp, struct in_addr addr, u_char *enaddr) +void __noinline +arp_announce_addr(struct ifnet *ifp, const struct in_addr *addr, u_char *enaddr) { - if (ntohl(addr.s_addr) != INADDR_ANY) - arprequest(ifp, &addr, &addr, enaddr); + if (ntohl(addr->s_addr) != INADDR_ANY) + arprequest(ifp, addr, addr, enaddr); } /* - * Sends gratuitous ARPs for each ifaddr to notify other - * nodes about the address change. + * Send gratuitous ARPs for all interfaces addresses to notify other nodes of + * changes. + * + * This is a noop if the interface isn't up or has been flagged for no ARP. */ -static __noinline void -arp_handle_ifllchange(struct ifnet *ifp) +void __noinline +arp_announce(struct ifnet *ifp) { + int i, cnt, entries; + u_char *lladdr; struct ifaddr *ifa; + struct in_addr *addr, *head; + if (!(ifp->if_flags & IFF_UP) || (ifp->if_flags & IFF_NOARP)) + return; + + entries = 8; + cnt = 0; + head = malloc(sizeof(*addr) * entries, M_TEMP, M_NOWAIT); + if (head == NULL) { + log(LOG_INFO, "arp_announce: malloc %d entries failed\n", + entries); + return; + } + + /* Take a copy then process to avoid locking issues. */ + IF_ADDR_RLOCK(ifp); TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { - if (ifa->ifa_addr->sa_family == AF_INET) - arp_ifinit(ifp, ifa); + if (ifa->ifa_addr->sa_family != AF_INET) + continue; + + if (cnt == entries) { + addr = (struct in_addr *)realloc(head, sizeof(*addr) * + (entries + 8), M_TEMP, M_NOWAIT); + if (addr == NULL) { + log(LOG_INFO, "arp_announce: realloc to %d " + "entries failed\n", entries + 8); + /* Process what we have. */ + break; + } + entries += 8; + head = addr; + } + + addr = head + cnt; + bcopy(IFA_IN(ifa), addr, sizeof(*addr)); + cnt++; } + IF_ADDR_RUNLOCK(ifp); + + lladdr = IF_LLADDR(ifp); + for (i = 0; i < cnt; i++) { + arp_announce_addr(ifp, head + i, lladdr); + } + free(head, M_TEMP); +} + +/* + * A handler for interface linkstate change events. + */ +static void +arp_ifnet_link_event(void *arg __unused, struct ifnet *ifp, int linkstate) +{ + + if (linkstate == LINK_STATE_UP && V_arp_on_link) + arp_announce(ifp); } /* - * A handler for interface link layer address change event. + * A handler for interface link layer address change events. */ static __noinline void arp_iflladdr(void *arg __unused, struct ifnet *ifp) { - if ((ifp->if_flags & IFF_UP) != 0) - arp_handle_ifllchange(ifp); + arp_announce(ifp); } static void @@ -1016,8 +1075,12 @@ arp_init(void) { netisr_register(&arp_nh); - if (IS_DEFAULT_VNET(curvnet)) + + if (IS_DEFAULT_VNET(curvnet)) { iflladdr_tag = EVENTHANDLER_REGISTER(iflladdr_event, arp_iflladdr, NULL, EVENTHANDLER_PRI_ANY); + ifnet_link_event_tag = EVENTHANDLER_REGISTER(ifnet_link_event, + arp_ifnet_link_event, 0, EVENTHANDLER_PRI_ANY); + } } SYSINIT(arp, SI_SUB_PROTO_DOMAIN, SI_ORDER_ANY, arp_init, 0); Index: sys/netinet/if_ether.h =================================================================== --- sys/netinet/if_ether.h (revision 291071) +++ sys/netinet/if_ether.h (working copy) @@ -120,7 +120,8 @@ int arpresolve(struct ifnet *ifp, struct void arprequest(struct ifnet *, const struct in_addr *, const struct in_addr *, u_char *); void arp_ifinit(struct ifnet *, struct ifaddr *); -void arp_announce_ifaddr(struct ifnet *, struct in_addr addr, u_char *); +void arp_announce(struct ifnet *); +void arp_announce_addr(struct ifnet *, const struct in_addr *addr, u_char *); void arp_ifscrub(struct ifnet *, uint32_t); #endif Index: sys/netinet/in_var.h =================================================================== --- sys/netinet/in_var.h (revision 291071) +++ sys/netinet/in_var.h (working copy) @@ -126,6 +126,9 @@ extern struct rwlock in_ifaddr_lock; #define IN_IFADDR_WLOCK_ASSERT() rw_assert(&in_ifaddr_lock, RA_WLOCKED) #define IN_IFADDR_WUNLOCK() rw_wunlock(&in_ifaddr_lock) +#define IFA_IN(ifa) \ + (&((struct sockaddr_in *)ifa->ifa_addr)->sin_addr) + /* * Macro for finding the internet address structure (in_ifaddr) * corresponding to one of our IP addresses (in_addr). Index: sys/netinet/ip_carp.c =================================================================== --- sys/netinet/ip_carp.c (revision 291071) +++ sys/netinet/ip_carp.c (working copy) @@ -1009,13 +1009,12 @@ static void carp_send_arp(struct carp_softc *sc) { struct ifaddr *ifa; - struct in_addr addr; CARP_FOREACH_IFA(sc, ifa) { if (ifa->ifa_addr->sa_family != AF_INET) continue; - addr = ((struct sockaddr_in *)ifa->ifa_addr)->sin_addr; - arp_announce_ifaddr(sc->sc_carpdev, addr, LLADDR(&sc->sc_addr)); + arp_announce_addr(sc->sc_carpdev, IFA_IN(ifa), + LLADDR(&sc->sc_addr)); } } @@ -1037,18 +1036,16 @@ carp_iamatch(struct ifaddr *ifa, uint8_t **enaddr) static void carp_send_na(struct carp_softc *sc) { - static struct in6_addr mcast = IN6ADDR_LINKLOCAL_ALLNODES_INIT; struct ifaddr *ifa; - struct in6_addr *in6; CARP_FOREACH_IFA(sc, ifa) { - if (ifa->ifa_addr->sa_family != AF_INET6) + if (ifa->ifa_addr->sa_family != AF_INET6 || + IFA_ND6_NA_UNSOLICITED_SKIP(ifa)) continue; - in6 = IFA_IN6(ifa); - nd6_na_output(sc->sc_carpdev, &mcast, in6, - ND_NA_FLAG_OVERRIDE, 1, NULL); - DELAY(1000); /* XXX */ + nd6_na_output_unsolicited_addr(sc->sc_carpdev, IFA_IN6(ifa), + IFA_ND6_NA_BASE_FLAGS(sc->sc_carpdev, ifa)); + nd6_na_unsolicited_addr_delay(ifa); } } Index: sys/netinet6/in6.c =================================================================== --- sys/netinet6/in6.c (revision 291071) +++ sys/netinet6/in6.c (working copy) @@ -113,7 +113,7 @@ VNET_DECLARE(int, icmp6_nodeinfo_oldmcprefix); #define V_icmp6_nodeinfo_oldmcprefix VNET(icmp6_nodeinfo_oldmcprefix) /* - * Definitions of some costant IP6 addresses. + * Definitions of some constant IP6 addresses. */ const struct in6_addr in6addr_any = IN6ADDR_ANY_INIT; const struct in6_addr in6addr_loopback = IN6ADDR_LOOPBACK_INIT; Index: sys/netinet6/in6_var.h =================================================================== --- sys/netinet6/in6_var.h (revision 291071) +++ sys/netinet6/in6_var.h (working copy) @@ -399,6 +399,16 @@ struct in6_rrenumreq { #define IA6_SIN6(ia) (&((ia)->ia_addr)) #define IA6_DSTSIN6(ia) (&((ia)->ia_dstaddr)) #define IFA_IN6(x) (&((struct sockaddr_in6 *)((x)->ifa_addr))->sin6_addr) +#define IFA_IN6_FLAGS(ifa) ((struct in6_ifaddr *)ifa)->ia6_flags +#define IFA_ND6_NA_BASE_FLAGS(ifp, ifa) \ + (IFA_IN6_FLAGS(ifa) & IN6_IFF_ANYCAST ? 0 : ND_NA_FLAG_OVERRIDE) | \ + ((V_ip6_forwarding && !(ND_IFINFO(ifp)->flags & ND6_IFF_ACCEPT_RTADV && \ + V_ip6_norbit_raif)) ? ND_NA_FLAG_ROUTER : 0) +#define IFA_ND6_NA_UNSOLICITED_SKIP(ifa) \ + (IFA_IN6_FLAGS(ifa) & (IN6_IFF_DUPLICATED | IN6_IFF_DEPRECATED | \ + IN6_IFF_TENTATIVE)) != 0 +#define IN6_MAX_ANYCAST_DELAY_TIME_MS 1000000 +#define IN6_BROADCAST_DELAY_TIME_MS 1000 #define IFA_DSTIN6(x) (&((struct sockaddr_in6 *)((x)->ifa_dstaddr))->sin6_addr) #define IFPR_IN6(x) (&((struct sockaddr_in6 *)((x)->ifpr_prefix))->sin6_addr) Index: sys/netinet6/nd6.c =================================================================== --- sys/netinet6/nd6.c (revision 291071) +++ sys/netinet6/nd6.c (working copy) @@ -39,6 +39,7 @@ __FBSDID("$FreeBSD: releng/10.2/sys/neti #include #include #include +#include #include #include #include @@ -103,8 +104,12 @@ VNET_DEFINE(int, nd6_maxnudhint) = 0; /* * layer hints */ static VNET_DEFINE(int, nd6_maxqueuelen) = 1; /* max pkts cached in unresolved * ND entries */ + +static VNET_DEFINE(int, nd6_on_link) = 1; /* Send unsolicited ND's on link up */ + #define V_nd6_maxndopt VNET(nd6_maxndopt) #define V_nd6_maxqueuelen VNET(nd6_maxqueuelen) +#define V_nd6_on_link VNET(nd6_on_link) #ifdef ND6_DEBUG VNET_DEFINE(int, nd6_debug) = 1; @@ -112,6 +117,8 @@ VNET_DEFINE(int, nd6_debug) = 1; VNET_DEFINE(int, nd6_debug) = 0; #endif +static eventhandler_tag ifnet_link_event_eh; + /* for debugging? */ #if 0 static int nd6_inuse, nd6_allocated; @@ -143,6 +150,14 @@ static VNET_DEFINE(struct callout, nd6_s VNET_DEFINE(struct callout, nd6_timer_ch); +static void +nd6_ifnet_link_event(void *arg __unused, struct ifnet *ifp, int linkstate) +{ + + if (linkstate == LINK_STATE_UP && V_nd6_on_link) + nd6_na_output_unsolicited(ifp); +} + void nd6_init(void) { @@ -158,6 +173,11 @@ nd6_init(void) nd6_slowtimo, curvnet); nd6_dad_init(); + + if (IS_DEFAULT_VNET(curvnet)) { + ifnet_link_event_eh = EVENTHANDLER_REGISTER(ifnet_link_event, + nd6_ifnet_link_event, NULL, EVENTHANDLER_PRI_ANY); + } } #ifdef VIMAGE @@ -167,6 +187,9 @@ nd6_destroy() callout_drain(&V_nd6_slowtimo_ch); callout_drain(&V_nd6_timer_ch); + if (IS_DEFAULT_VNET(curvnet)) { + EVENTHANDLER_DEREGISTER(ifnet_link_event, ifnet_link_event_eh); + } } #endif @@ -2250,13 +2273,18 @@ static int nd6_sysctl_prlist(SYSCTL_HAND SYSCTL_DECL(_net_inet6_icmp6); #endif SYSCTL_NODE(_net_inet6_icmp6, ICMPV6CTL_ND6_DRLIST, nd6_drlist, - CTLFLAG_RD, nd6_sysctl_drlist, ""); + CTLFLAG_RD, nd6_sysctl_drlist, "List default routers"); SYSCTL_NODE(_net_inet6_icmp6, ICMPV6CTL_ND6_PRLIST, nd6_prlist, - CTLFLAG_RD, nd6_sysctl_prlist, ""); + CTLFLAG_RD, nd6_sysctl_prlist, "List prefixes"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_MAXQLEN, nd6_maxqueuelen, - CTLFLAG_RW, &VNET_NAME(nd6_maxqueuelen), 1, ""); + CTLFLAG_RW, &VNET_NAME(nd6_maxqueuelen), 1, + "Max packets cached in unresolved ND entries"); SYSCTL_VNET_INT(_net_inet6_icmp6, OID_AUTO, nd6_gctimer, - CTLFLAG_RW, &VNET_NAME(nd6_gctimer), (60 * 60 * 24), ""); + CTLFLAG_RW, &VNET_NAME(nd6_gctimer), (60 * 60 * 24), + "Interface in seconds between garbage collection passes"); +SYSCTL_INT(_net_inet6_icmp6, OID_AUTO, nd6_on_link, CTLFLAG_VNET | CTLFLAG_RW, + &VNET_NAME(nd6_on_link), 0, + "Send unsolicited neighbor discovery on interface link up events"); static int nd6_sysctl_drlist(SYSCTL_HANDLER_ARGS) Index: sys/netinet6/nd6.h =================================================================== --- sys/netinet6/nd6.h (revision 291071) +++ sys/netinet6/nd6.h (working copy) @@ -398,6 +398,10 @@ void nd6_init(void); #ifdef VIMAGE void nd6_destroy(void); #endif +void nd6_na_output_unsolicited(struct ifnet *); +void nd6_na_output_unsolicited_addr(struct ifnet *, const struct in6_addr *, + u_long); +int nd6_na_unsolicited_addr_delay(struct ifaddr *); struct nd_ifinfo *nd6_ifattach(struct ifnet *); void nd6_ifdetach(struct nd_ifinfo *); int nd6_is_addr_neighbor(const struct sockaddr_in6 *, struct ifnet *); Index: sys/netinet6/nd6_nbr.c =================================================================== --- sys/netinet6/nd6_nbr.c (revision 291071) +++ sys/netinet6/nd6_nbr.c (working copy) @@ -124,20 +124,16 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len struct in6_addr saddr6 = ip6->ip6_src; struct in6_addr daddr6 = ip6->ip6_dst; struct in6_addr taddr6; - struct in6_addr myaddr6; char *lladdr = NULL; struct ifaddr *ifa = NULL; + u_long flags; int lladdrlen = 0; - int anycast = 0, proxy = 0, tentative = 0; + int proxy = 0; int tlladdr; - int rflag; union nd_opts ndopts; struct sockaddr_dl proxydl; char ip6bufs[INET6_ADDRSTRLEN], ip6bufd[INET6_ADDRSTRLEN]; - rflag = (V_ip6_forwarding) ? ND_NA_FLAG_ROUTER : 0; - if (ND_IFINFO(ifp)->flags & ND6_IFF_ACCEPT_RTADV && V_ip6_norbit_raif) - rflag = 0; #ifndef PULLDOWN_TEST IP6_EXTHDR_CHECK(m, off, icmp6len,); nd_ns = (struct nd_neighbor_solicit *)((caddr_t)ip6 + off); @@ -229,10 +225,7 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len * In implementation, we add target link-layer address by default. * We do not add one in MUST NOT cases. */ - if (!IN6_IS_ADDR_MULTICAST(&daddr6)) - tlladdr = 0; - else - tlladdr = 1; + tlladdr = !IN6_IS_ADDR_MULTICAST(&daddr6); /* * Target address (taddr6) must be either: @@ -289,9 +282,6 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len */ goto freeit; } - myaddr6 = *IFA_IN6(ifa); - anycast = ((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_ANYCAST; - tentative = ((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_TENTATIVE; if (((struct in6_ifaddr *)ifa)->ia6_flags & IN6_IFF_DUPLICATED) goto freeit; @@ -303,7 +293,7 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len goto bad; } - if (IN6_ARE_ADDR_EQUAL(&myaddr6, &saddr6)) { + if (IN6_ARE_ADDR_EQUAL(IFA_IN6(ifa), &saddr6)) { nd6log((LOG_INFO, "nd6_ns_input: duplicate IP6 address %s\n", ip6_sprintf(ip6bufs, &saddr6))); goto freeit; @@ -321,7 +311,7 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len * * The processing is defined in RFC 2462. */ - if (tentative) { + if (IFA_IN6_FLAGS(ifa) & IN6_IFF_TENTATIVE) { /* * If source address is unspecified address, it is for * duplicate address detection. @@ -335,6 +325,10 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len goto freeit; } + flags = IFA_ND6_NA_BASE_FLAGS(ifp, ifa); + if (proxy || !tlladdr) + flags &= ~ND_NA_FLAG_OVERRIDE; + /* * If the source address is unspecified address, entries must not * be created or updated. @@ -349,10 +343,8 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len in6_all = in6addr_linklocal_allnodes; if (in6_setscope(&in6_all, ifp, NULL) != 0) goto bad; - nd6_na_output_fib(ifp, &in6_all, &taddr6, - ((anycast || proxy || !tlladdr) ? 0 : ND_NA_FLAG_OVERRIDE) | - rflag, tlladdr, proxy ? (struct sockaddr *)&proxydl : NULL, - M_GETFIB(m)); + nd6_na_output_fib(ifp, &in6_all, &taddr6, flags, tlladdr, + proxy ? (struct sockaddr *)&proxydl : NULL, M_GETFIB(m)); goto freeit; } @@ -359,10 +351,8 @@ nd6_ns_input(struct mbuf *m, int off, int icmp6len nd6_cache_lladdr(ifp, &saddr6, lladdr, lladdrlen, ND_NEIGHBOR_SOLICIT, 0); - nd6_na_output_fib(ifp, &saddr6, &taddr6, - ((anycast || proxy || !tlladdr) ? 0 : ND_NA_FLAG_OVERRIDE) | - rflag | ND_NA_FLAG_SOLICITED, tlladdr, - proxy ? (struct sockaddr *)&proxydl : NULL, M_GETFIB(m)); + nd6_na_output_fib(ifp, &saddr6, &taddr6, flags | ND_NA_FLAG_SOLICITED, + tlladdr, proxy ? (struct sockaddr *)&proxydl : NULL, M_GETFIB(m)); freeit: if (ifa != NULL) ifa_free(ifa); @@ -1589,3 +1579,110 @@ nd6_dad_na_input(struct ifaddr *ifa) nd6_dad_rele(dp); } } + +/* + * Send unsolicited neighbor advertisements for all interface addresses to + * notify other nodes of changes. + * + * This is a noop if the interface isn't up. + */ +void __noinline +nd6_na_output_unsolicited(struct ifnet *ifp) +{ + int i, cnt, entries; + struct ifaddr *ifa; + struct ann { + struct in6_addr addr; + u_long flags; + int delay; + } *ann1, *head; + + if (!(ifp->if_flags & IFF_UP)) + return; + + entries = 8; + cnt = 0; + head = malloc(sizeof(struct ann) * entries, M_TEMP, M_WAITOK); + + /* Take a copy then process to avoid locking issues. */ + IF_ADDR_RLOCK(ifp); + TAILQ_FOREACH(ifa, &ifp->if_addrhead, ifa_link) { + if (ifa->ifa_addr->sa_family != AF_INET6 || + IFA_ND6_NA_UNSOLICITED_SKIP(ifa)) + continue; + + if (cnt == entries) { + ann1 = (struct ann*)realloc(head, sizeof(struct ann) * + (entries + 8), M_TEMP, M_NOWAIT); + if (ann1 == NULL) { + log(LOG_INFO, "nd6_announce: realloc to %d " + "entries failed\n", entries + 8); + /* Process what we have. */ + break; + } + entries += 8; + head = ann1; + } + + ann1 = head + cnt; + bcopy(IFA_IN6(ifa), &ann1->addr, sizeof(ann1->addr)); + ann1->flags = IFA_ND6_NA_BASE_FLAGS(ifp, ifa); + ann1->delay = nd6_na_unsolicited_addr_delay(ifa); + cnt++; + } + IF_ADDR_RUNLOCK(ifp); + + for (i = 0; i < cnt;) { + ann1 = head + i; + nd6_na_output_unsolicited_addr(ifp, &ann1->addr, ann1->flags); + i++; + if (i == cnt) + break; + DELAY(ann1->delay); + } + free(head, M_TEMP); +} + +/* + * Return the delay required for announcements of the address as per RFC 4861. + */ +int +nd6_na_unsolicited_addr_delay(struct ifaddr *ifa) +{ + + if (IFA_IN6_FLAGS(ifa) & IN6_IFF_ANYCAST) { + /* + * Random value between 0 and MAX_ANYCAST_DELAY_TIME + * as per section 7.2.7. + */ + return (random() % IN6_MAX_ANYCAST_DELAY_TIME_MS); + } + + /* Small delay as per section 7.2.6. */ + return (IN6_BROADCAST_DELAY_TIME_MS); +} + +/* + * Send an unsolicited neighbor advertisement for an address to notify other + * nodes of changes. + */ +void __noinline +nd6_na_output_unsolicited_addr(struct ifnet *ifp, const struct in6_addr *addr, + u_long flags) +{ + int error; + struct in6_addr mcast; + + mcast = in6addr_linklocal_allnodes; + if ((error = in6_setscope(&mcast, ifp, NULL)) != 0) { + /* + * This shouldn't by possible as the only error is for loopback + * address which we're not using. + */ + log(LOG_INFO, "in6_setscope: on mcast failed: %d\n", error); + return; + } + nd6_na_output(ifp, &mcast, addr, flags, 1, NULL); +} + + --------------8DA201AA1DCCAD657B20F1BD-- From owner-freebsd-net@freebsd.org Tue Sep 6 08:48:19 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48D9BB9620D for ; Tue, 6 Sep 2016 08:48:19 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD4178F2 for ; Tue, 6 Sep 2016 08:48:18 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.106] (vpn01-01.tdx.co.uk [62.13.130.213] (may be forged)) (authenticated bits=0) by smtp.krpservers.com (8.15.2/8.15.2) with ESMTPSA id u868mFnx032869 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Sep 2016 09:48:16 +0100 (BST) (envelope-from kpielorz_lst@tdx.co.uk) Date: Tue, 06 Sep 2016 09:48:04 +0100 From: Karl Pielorz To: freebsd-net@FreeBSD.org Subject: Re: lagg Interfaces - don't do Gratuitous ARP? Message-ID: In-Reply-To: <0D84203FAAFD0A8E7BBB24A3@[10.12.30.106]> References: <0D84203FAAFD0A8E7BBB24A3@[10.12.30.106]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 06 Sep 2016 08:48:19 -0000 --On 06 September 2016 09:13 +0100 Karl Pielorz wrote: > We've just changed the network config on a box - going from a single > 'em1' adapter to a lagg failover of em0, em1. Sorry - not enough coffee yet, I should have said this is on FreeBSD 10.3-RELEASE-p7 amd64... -Karl From owner-freebsd-net@freebsd.org Tue Sep 6 17:11:13 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47860BC66BC for ; Tue, 6 Sep 2016 17:11:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 360A53E0 for ; Tue, 6 Sep 2016 17:11:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u86HBCUk092585 for ; Tue, 6 Sep 2016 17:11:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 212331] pfil processing order Date: Tue, 06 Sep 2016 17:11:13 +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: 10.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 06 Sep 2016 17:11:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212331 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-i386@FreeBSD.org | Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Sep 6 19:48:35 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA977BC6C58 for ; Tue, 6 Sep 2016 19:48:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 930AF7ED for ; Tue, 6 Sep 2016 19:48:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u86JmZNV003968 for ; Tue, 6 Sep 2016 19:48:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 212283] oversized IP datagrams on raw socket with IP_RAWOUTPUT hang network interface drivers Date: Tue, 06 Sep 2016 19:48:35 +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: 11.0-RC1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 06 Sep 2016 19:48:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212283 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|network watchdog timeout |oversized IP datagrams on |with some raw sockets usage |raw socket with | |IP_RAWOUTPUT hang network | |interface drivers --- Comment #11 from Gleb Smirnoff --- I think we shouldn't tweak the ip_len in the kernel. If userland --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Sep 6 19:49:47 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8442BC6CD1 for ; Tue, 6 Sep 2016 19:49:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 97CB08FF for ; Tue, 6 Sep 2016 19:49:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u86JnkZT005618 for ; Tue, 6 Sep 2016 19:49:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 212283] oversized IP datagrams on raw socket with IP_RAWOUTPUT hang network interface drivers Date: Tue, 06 Sep 2016 19:49:47 +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: 11.0-RC1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 06 Sep 2016 19:49:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212283 --- Comment #12 from Gleb Smirnoff --- I think we shouldn't tweak the ip_len in the kernel. If userland supplies oversized datagram, greater than interface MTU, we should just drop it silently. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Tue Sep 6 19:52:02 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F163EBC6EEB for ; Tue, 6 Sep 2016 19:52:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 DC40DCF2 for ; Tue, 6 Sep 2016 19:52:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u86Jq2NN013640 for ; Tue, 6 Sep 2016 19:52:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 212283] oversized IP datagrams on raw socket with IP_RAWOUTPUT hang network interface drivers Date: Tue, 06 Sep 2016 19:52:02 +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: 11.0-RC1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 06 Sep 2016 19:52:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212283 --- Comment #13 from Gleb Smirnoff --- Not silently. Better return EFBIG to userland. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Sep 7 08:50:44 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB99FB719EF for ; Wed, 7 Sep 2016 08:50:44 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6709A82B for ; Wed, 7 Sep 2016 08:50:43 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.106] (vpn01-01.tdx.co.uk [62.13.130.213] (may be forged)) (authenticated bits=0) by smtp.krpservers.com (8.15.2/8.15.2) with ESMTPSA id u878oZu2029777 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Sep 2016 09:50:36 +0100 (BST) (envelope-from kpielorz_lst@tdx.co.uk) Date: Wed, 07 Sep 2016 09:50:21 +0100 From: Karl Pielorz To: Steven Hartland , freebsd-net@freebsd.org Subject: Re: lagg Interfaces - don't do Gratuitous ARP? Message-ID: <6E574F1B61786E6032824A88@[10.12.30.106]> In-Reply-To: References: <0D84203FAAFD0A8E7BBB24A3@[10.12.30.106]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 07 Sep 2016 08:50:44 -0000 --On 06 September 2016 09:42 +0100 Steven Hartland wrote: > Yes known issue I'm afraid. > > I created a patch set to address this but there where objections so it > was removed, see the attached which is based on 10.2-RELEASE. Hi, Thanks for the reply, and the comprehensive patch. If I get a chance I'll see if I can run it up one of the affected boxes, if I can find one I can mess around with. Good to know it wasn't just "me" :) Cheers, -Karl From owner-freebsd-net@freebsd.org Wed Sep 7 10:29:37 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 731F8BCF85C for ; Wed, 7 Sep 2016 10:29:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 629F2BB2 for ; Wed, 7 Sep 2016 10:29:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u87ATZNq096135 for ; Wed, 7 Sep 2016 10:29:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 208205] re0 watchdog timeout Date: Wed, 07 Sep 2016 10:29:35 +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: 10.3-BETA2 X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ml@netfence.it X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 07 Sep 2016 10:29:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208205 ml@netfence.it changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ml@netfence.it --- Comment #10 from ml@netfence.it --- Just a "me too" here... The box is a 10.3p5 running as a router/server. The internal interface (re0) got blocked (just once luckily until now). The outside interface (re1) was working, so I could log in remotely and reb= oot; ifconfig re0 down/up would not help. powerd is running in its default config (i.e. just powerd_enable=3D"YES" in /etc/rc.conf). PF is not running, but IPFW is. # pciconf -lv ... re0@pci0:2:0:0: class=3D0x020000 card=3D0x78171462 chip=3D0x816810ec rev=3D= 0x0c hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet re1@pci0:3:0:0: class=3D0x020000 card=3D0x34687470 chip=3D0x816810ec rev=3D= 0x06 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Wed Sep 7 11:30:46 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35117BCF0AA for ; Wed, 7 Sep 2016 11:30:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 1ABDA834 for ; Wed, 7 Sep 2016 11:30:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u87BUjjd066018 for ; Wed, 7 Sep 2016 11:30:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 208205] re0 watchdog timeout Date: Wed, 07 Sep 2016 11:30:45 +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: 10.3-BETA2 X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: c.kworr@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.23 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, 07 Sep 2016 11:30:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208205 --- Comment #11 from c.kworr@gmail.com --- (In reply to Sean Bruno from comment #8) Actually you can be right. During boot I always have this LOR: Sep 7 10:08:26 limbo kernel: lock order reversal: Sep 7 10:08:26 limbo kernel: 1st 0xffffffff818f5b80 pf rulesets (pf rulese= ts) @ /usr/src/sys/modules/pf/../../netpfil/pf/pf.c:5879 Sep 7 10:08:26 limbo kernel: 2nd 0xffffffff80d4a6c8 pcbinfohash (pcbinfoha= sh) @ /usr/src/sys/netinet/in_pcb.c:1957 Sep 7 10:08:26 limbo kernel: stack backtrace: Sep 7 10:08:26 limbo kernel: #0 0xffffffff8040af80 at witness_debugger+0x70 Sep 7 10:08:26 limbo kernel: #1 0xffffffff8040ae74 at witness_checkorder+0= xe54 Sep 7 10:08:26 limbo kernel: #2 0xffffffff803a8647 at __rw_rlock+0xa7 Sep 7 10:08:26 limbo kernel: #3 0xffffffff804d369f at in_pcblookup_hash+0x= 3f Sep 7 10:08:26 limbo kernel: #4 0xffffffff818c75e5 at pf_socket_lookup+0xe5 Sep 7 10:08:26 limbo kernel: #5 0xffffffff818cdbc7 at pf_test_rule+0x1817 Sep 7 10:08:26 limbo kernel: #6 0xffffffff818c9254 at pf_test+0x18f4 Sep 7 10:08:26 limbo kernel: #7 0xffffffff818dc5dd at pf_check_out+0x1d Sep 7 10:08:26 limbo kernel: #8 0xffffffff804b890b at pfil_run_hooks+0x8b Sep 7 10:08:26 limbo kernel: #9 0xffffffff804d5bc5 at ip_tryforward+0x295 Sep 7 10:08:26 limbo kernel: #10 0xffffffff804d818f at ip_input+0x35f Sep 7 10:08:26 limbo kernel: #11 0xffffffff804b77c0 at netisr_dispatch_src+0x80 Sep 7 10:08:26 limbo kernel: #12 0xffffffff804a2fea at ether_demux+0x14a Sep 7 10:08:26 limbo kernel: #13 0xffffffff804a3de0 at ether_nh_input+0x340 Sep 7 10:08:26 limbo kernel: #14 0xffffffff804b77c0 at netisr_dispatch_src+0x80 Sep 7 10:08:26 limbo kernel: #15 0xffffffff804a3352 at ether_input+0x62 Sep 7 10:08:26 limbo kernel: #16 0xffffffff817d9f75 at re_rxeof+0x5c5 Sep 7 10:08:26 limbo kernel: #17 0xffffffff817d75ba at re_intr_msi+0xca re0@pci0:2:0:0: class=3D0x020000 card=3D0x4b101186 chip=3D0x43001186 rev=3D= 0x06 hdr=3D0x00 vendor =3D 'D-Link System Inc' device =3D 'DGE-528T Gigabit Ethernet Adapter' class =3D network subclass =3D ethernet re1@pci0:3:0:0: class=3D0x020000 card=3D0x230e1565 chip=3D0x816810ec rev=3D= 0x07 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controll= er' class =3D network subclass =3D ethernet Only re1 fails. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-net@freebsd.org Fri Sep 9 22:29:09 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C0FCBD44D9 for ; Fri, 9 Sep 2016 22:29:09 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 DC0E0DE9 for ; Fri, 9 Sep 2016 22:29:07 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5B227477.dip0.t-ipconnect.de [91.34.116.119]) (authenticated bits=128) by land.berklix.org (8.15.2/8.15.2) with ESMTPA id u89MSssV087568; Fri, 9 Sep 2016 22:28:54 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id u89MSqWI015191; Sat, 10 Sep 2016 00:28:53 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id u89MSeUn099239; Sat, 10 Sep 2016 00:28:52 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201609092228.u89MSeUn099239@fire.js.berklix.net> To: freebsd-net@freebsd.org cc: "Julian H. Stacey" Subject: possible disruption of dovecot traffic on 1 of 2 freebsd hosts From: "Julian H. Stacey" Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ Date: Sat, 10 Sep 2016 00:28:40 +0200 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 09 Sep 2016 22:29:09 -0000 Hi freebsd-net@freebsd.org I'm seeing strange net behaviour with POP3 on 1 of 2 servers, I would appreciate advice please, perhaps name of net tools to test with ? I have 1 local client POP3 fed from 2 remote servers: land.berklix.org a jail under another FreeBSD. FreeBSD land.berklix.org 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 slim.berklix.org under vmware, dont know whats outside FreeBSD slim.berklix.org 10.3-STABLE FreeBSD 10.3-STABLE #0: Tue Aug 16 18:09:22 CEST 2016 jhs@slim.berklix.org:/usr/obj/usr/src/sys/GENERIC amd64 slim also has /etc/rc.conf vmware_guest_vmblock_enable="YES" vmware_guest_vmhgfs_enable="YES" vmware_guest_vmmemctl_enable="YES" # ports/emulators/open-vm-tools-nox11 vmware_guest_vmxnet_enable="YES" # ports/emulators/open-vm-tools-nox11 vmware_guestd_enable="YES" # ports/emulators/open-vm-tools-nox11 Both land & slim run POP3 servers: /usr/ports/mail/dovecot # pkg info | grep dovecot # dovecot-1.2.17_6 All src/ & ports/ self compiled (though not kernels of prison & vmware). host land is reliable I can always succeed with fetchmail land.berklix.org host slim I can fetchmail for a while, then it locks up & periodically & I must manualy mv & sftp /var/mail/jhs The receiving local client shows this: fetchmail -v -v slim.berklix.org ........ fetchmail: SMTP> MAIL FROM: SIZE=14380 fetchmail: SMTP< 250 2.1.0 ... Sender ok fetchmail: SMTP> RCPT TO: fetchmail: SMTP< 250 2.1.5 ... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself #**************************.**********************.************************.**************.*************.**************.**************.**************.**************.**************.*************.**************.**********fetchmail: socket error while fetching from jhs@slim.berklix.org fetchmail: 6.3.8 querying slim.berklix.org (protocol POP3) at Fri Sep 9 22:49:31 2016: poll completed fetchmail: discarding new UID list fetchmail: Query status=2 (SOCKET) fetchmail: Deleting fetchids file. fetchmail: normal termination, status 2 fetchmail: Deleting fetchids file. /var/log/maillog: Land: dovecot: POP3(jhs): Disconnected: Logged out top=0/0, retr=0/0, del=0/0, size=0 Slim: dovecot: POP3(jhs): Connection closed: Connection reset by peer top=1/14385, retr=0/0, del=0/9, size=112436 Nothing suspicious in /var/log/messages on slim Strangely, I can sftp this /var/mail/jhs data to host=land, then I can fetchmail it from host=land no problem. Makes me suspect a packet problem ? I have kept 2 samples of that data, so can repeat this. I've noticed some stickiness on ssh session to host=slim in last weeks (& slim is a newish (some weeks) re-installation of FreeBSD on a newish vmwaee host (previous hardware problem) so something might have changed.) I'm wondering what tools to use to analyse & compare connections between home to both servers ? Reccomendations from /usr/ports/net/ I guess ? I'm rusty, but I guess it can't be eg something like long ago DSL MTU length issue, cos the same DSL link when up, works fine from host=land, just not from host=slim Can't be something weird in my dovecot POP3 server config, because both have identical symbolic links /usr/local/etc/dovecot.conf -> ../../../site/usr/local/etc/dovecot.conf & /site is frequently updated on both to keep identical my .fetchmailrc entries to fetch from both server are symmetric too. It's not some differential packet filtering in kernel issue, as with ipfw show land (jailed, work ok) ipfw: socket: Operation not permitted slim (vmware, locks up occasionaly, Ive not compiled ipfw in my kernel) ipfw: getsockopt(IP_FW_GET): Protocol not available I do have an ipfw rule set on my home gate, but neither those nor the 2 IPs of remote server have changed in a long time, I wrote them symmetricly way back, used to work on both, can't be that. Top shows both hosts 96 to 99% idle most of the time. Any suggestion of net / packet performance tools I might run please ? PS I am subscribed to net@freebsd.org, but a CC to me also nice, Thanks ! Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#stolen_votes From owner-freebsd-net@freebsd.org Sat Sep 10 00:04:40 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26639BD2BB0 for ; Sat, 10 Sep 2016 00:04:40 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id F31B7A12 for ; Sat, 10 Sep 2016 00:04:39 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-24-5-143-190.hsd1.ca.comcast.net [24.5.143.190]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id u8A04XPu029658 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 9 Sep 2016 17:04:33 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-5-143-190.hsd1.ca.comcast.net [24.5.143.190] claimed to be yuri.doctorlan.com To: freebsd-net@freebsd.org From: Yuri Subject: Search for SANE scanners freezes the system Message-ID: <6b3e68d6-9add-bb25-9bbe-58d1721ab9d1@rawbw.com> Date: Fri, 9 Sep 2016 17:04:31 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 10 Sep 2016 00:04:40 -0000 I observe this weird fenomenon: scanimage (from graphics/sane-backends) freezes the system when it doesn't find a scanner on the LAN, and works fine when the scanner is found. The only thing that scanimage does is sending UDP broadcasts, this makes me think this is network related. The problem occurs reliably. Nothing is printed to the system log. Anybody happens to know what might be the problem? 10.3 amd64 Yuri From owner-freebsd-net@freebsd.org Sat Sep 10 00:33:59 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53CE9BD4222 for ; Sat, 10 Sep 2016 00:33:59 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19B266D1 for ; Sat, 10 Sep 2016 00:33:59 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id y2so176419197oie.0 for ; Fri, 09 Sep 2016 17:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ke3pFbR/MVJQgDSekBkkmjQCZ9egVin4/RawKhsy4KA=; b=uP0Hky09wMEgIt53ssQUws/cwydEgtBY2pVip+e7Ij90gqo0zGEXXkKP7G/vhIDe4D jHTZvTFnAzmb0LrfXgZSjqZj8qpKcg1rEeWGpzDlap+5w3WzwHk5hgEpr9HnQyLQfQqW WSsNSC7TtTYDGHP/yCDhjTswzp87FBHhrfyw+G7dOF49LAH6KUczAKDEjSVsn+ROrBWx hM/XeXQxWERI+CfuohJc+yJ0qhvbd73KZPBzOd0Kjo4iZjta/tbgFth1UYcj/6F8rsXU HUakbLFU/gmgb559S1dtcgcqnolohJiLsLGZLbAm02VzwKvod+EtukqHv6W2XtdsPsrH 0wyw== 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:from:date :message-id:subject:to:cc; bh=ke3pFbR/MVJQgDSekBkkmjQCZ9egVin4/RawKhsy4KA=; b=GWmLF4Pk7RVIamebizz806rPlW9lZH1ALEuPsG3z7fVrVXuR3pPjmmgc4A9JoUgOYZ 0nf77IqXzUxoaNSnjt+qQOLQtsZqBv7cjRAG9OHBztwOBBIj0W8qunoSxK+X6Bor6wUF q2xFjlu6Jllh7nzAaX/GbGlTybn2awJtLrd4Dz41BV1mqyOe8DaE1kLdzi6lAeld0+ye 7MJ0YgqUAtqX44xU5ORocYODIKeOv3o/A43yaWyS1xVVE7UPTOZ+yuLf/C+1spFLLGWF Y/WMmHouxLoMLzHzkvuRFNpbdYVOOKDYGBgYWUF8i1FZgNDM/Grv5Ef11daMt7B2F6xl ASww== X-Gm-Message-State: AE9vXwM57j91Pu7BEBYKRdGMwm6SE0DO8ONTUtS8ELjd8zNta48winLKw5FF6tD2XwmQQe0v6fWcCTycqLIsZA== X-Received: by 10.157.60.246 with SMTP id t51mr8974673otf.129.1473467638237; Fri, 09 Sep 2016 17:33:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.26.3 with HTTP; Fri, 9 Sep 2016 17:33:57 -0700 (PDT) In-Reply-To: <6b3e68d6-9add-bb25-9bbe-58d1721ab9d1@rawbw.com> References: <6b3e68d6-9add-bb25-9bbe-58d1721ab9d1@rawbw.com> From: Ben Woods Date: Sat, 10 Sep 2016 08:33:57 +0800 Message-ID: Subject: Re: Search for SANE scanners freezes the system To: Yuri Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 10 Sep 2016 00:33:59 -0000 On Saturday, 10 September 2016, Yuri wrote: > I observe this weird fenomenon: scanimage (from graphics/sane-backends) > freezes the system when it doesn't find a scanner on the LAN, and works > fine when the scanner is found. > > The only thing that scanimage does is sending UDP broadcasts, this makes > me think this is network related. The problem occurs reliably. Nothing is > printed to the system log. > > > Anybody happens to know what might be the problem? > > > 10.3 amd64 > > > Yuri > Hi Yuri, Can you please define more what you mean by "freezes the system"? Does it panic the kernel (which either reboots itself or drops you to a debugging console)? Does the command line just not output anything and not return to the prompt? In this case, maybe a Ctrl+c will exit the scanimage program and return you to the prompt? Or does it freeze your scanner (I.e. The impact is on your scanner, leaving your FreeBSD machine running fine)? Regards, Ben -- -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-net@freebsd.org Sat Sep 10 12:51:56 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEDE4BD4E89 for ; Sat, 10 Sep 2016 12:51:56 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B71E91A2; Sat, 10 Sep 2016 12:51:56 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pa0-x229.google.com with SMTP id id6so36940633pad.3; Sat, 10 Sep 2016 05:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ieUe+NQu9bBEwiuFuoPW2zaQj527Fbqpf3d7+1opZOs=; b=nKFBx2m3P3p21M9L1IshbMx4EwSvWasHkSASpGuj0LC263BzX/Cd/4DYqyQf64rdva DoANI+Xz/uwSjgCA55cvdxHP9xIS3x+mof/S+7CmPFMlXK7O7XbSbqk63mAcf45UVzn2 KqADJTph83AfobKIro7n0qjv78tdIW6HlX8p/2uFfuKKA0ErlKRKO2dnO/w9rgBYnNDs U34CINd0tv86UkvwZE+TsZmGoM12Hc6/LNjN0a4AXfp02rJoFfa3JWdZIBd5mXpDOjac Vgu6wzy8IZwVFNfSSLSi6o4r+LiSg0bUyqitkjeX2zh1MPcIBWTo4maIZgEYcd0uX/8G /nUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:reply-to:subject:references:to:from:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ieUe+NQu9bBEwiuFuoPW2zaQj527Fbqpf3d7+1opZOs=; b=SbMFncuAD8xtL/P6ULpWuSPzZo+d9sd0YeQQ8CZ2l5HFs0P0sVMufjAZH1J/vnGIhr j2eDDoLkKxeuanqbYM0jDRwenFEjlIRoWMgdm8roU6FsjypyebCL/8wK8Z2P4vS5GI2q T5zCTBnHpnn3m7P/f3xiT7orCImbcotDRK3878gBL+0OC+RswTZtqK0OBp+kEtQF8Z77 DyCcJU4UaPD97mUOb5WCgItewmX4M+xgKG4ytPEgPGrcoA2DFDZtrWD8ptrCOd+Vk/iV /JxlcxKYfz0OP2apfbAy7J+vsDXOPb/SImazge2beBwb3gt7KI083vm4XW4HDGs3NYPT +pnA== X-Gm-Message-State: AE9vXwO2sV5VxwuHEtN+3BjOaTdAoEC0fprIDU7P1XId8lfjJzYuQObLvvMsd5ukfJFZnw== X-Received: by 10.66.43.113 with SMTP id v17mr15647741pal.112.1473511916123; Sat, 10 Sep 2016 05:51:56 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b01:1c1a:5103:265d:bfaf? (2001-44b8-31ae-7b01-1c1a-5103-265d-bfaf.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:1c1a:5103:265d:bfaf]) by smtp.gmail.com with ESMTPSA id e1sm12262955pap.11.2016.09.10.05.51.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Sep 2016 05:51:55 -0700 (PDT) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: lagg Interfaces - don't do Gratuitous ARP? References: <0D84203FAAFD0A8E7BBB24A3@[10.12.30.106]> <6E574F1B61786E6032824A88@[10.12.30.106]> To: Karl Pielorz , freebsd-net@freebsd.org From: Kubilay Kocak Cc: Steven Hartland , Gleb Smirnoff Message-ID: <2c62f5f0-3fb4-f513-2a8f-02de3a1d552f@FreeBSD.org> Date: Sat, 10 Sep 2016 22:51:36 +1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Thunderbird/50.0a2 MIME-Version: 1.0 In-Reply-To: <6E574F1B61786E6032824A88@[10.12.30.106]> Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 10 Sep 2016 12:51:57 -0000 On 7/09/2016 6:50 PM, Karl Pielorz wrote: > > > --On 06 September 2016 09:42 +0100 Steven Hartland > wrote: > >> Yes known issue I'm afraid. >> >> I created a patch set to address this but there where objections so >> it was removed, see the attached which is based on 10.2-RELEASE. > > Hi, > > Thanks for the reply, and the comprehensive patch. If I get a chance > I'll see if I can run it up one of the affected boxes, if I can find > one I can mess around with. > > Good to know it wasn't just "me" :) > > Cheers, > > -Karl Also see the following review, which was re-opened (after original commit was reverted) after said issues were raised, though I can't see that glebius has commented on it since: https://reviews.freebsd.org/D4111 11.0 having this would have been awesome. Maybe (hopefully) 11.1 ./koobs From owner-freebsd-net@freebsd.org Sat Sep 10 16:04:16 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD3B3BD404E for ; Sat, 10 Sep 2016 16:04:16 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id BD995F6A for ; Sat, 10 Sep 2016 16:04:16 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yuri.doctorlan.com (c-24-5-143-190.hsd1.ca.comcast.net [24.5.143.190]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id u8AG4FSo029928 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 10 Sep 2016 09:04:15 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-5-143-190.hsd1.ca.comcast.net [24.5.143.190] claimed to be yuri.doctorlan.com Subject: Re: Search for SANE scanners freezes the system To: Ben Woods References: <6b3e68d6-9add-bb25-9bbe-58d1721ab9d1@rawbw.com> Cc: "freebsd-net@freebsd.org" From: Yuri Message-ID: <11f0efa3-cb9f-9a99-48bf-ae1a13d31aaa@rawbw.com> Date: Sat, 10 Sep 2016 09:04:14 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 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, 10 Sep 2016 16:04:16 -0000 On 09/09/2016 17:33, Ben Woods wrote: > Can you please define more what you mean by "freezes the system"? > > Does it panic the kernel (which either reboots itself or drops you to a > debugging console)? > > Does the command line just not output anything and not return to the > prompt? In this case, maybe a Ctrl+c will exit the scanimage program and > return you to the prompt? > > Or does it freeze your scanner (I.e. The impact is on your scanner, leaving > your FreeBSD machine running fine)? System doesn't panic, it just stops, the same image stays on the graphics screen, keyboard/mouse become dead, and it doesn't respond to the network queries. I am thinking that this command sends some unusual broadcasts that possibly expose some bug. I think I can reproduce it reliably on my system. But I am not sure where to go from here. Yuri