From owner-freebsd-net@freebsd.org Sun Jan 10 13:32:27 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8F0B94CC6D7 for ; Sun, 10 Jan 2021 13:32:27 +0000 (UTC) (envelope-from shamaz.mazum@gmail.com) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDHnl3C2jz4f52; Sun, 10 Jan 2021 13:32:27 +0000 (UTC) (envelope-from shamaz.mazum@gmail.com) Received: by mail-oi1-x232.google.com with SMTP id 15so17287815oix.8; Sun, 10 Jan 2021 05:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eKNe2T3inhmjTnTRQH69fXGTQtYTYo0ljmxCi/IFgUQ=; b=VBDDHhlNDjhITkYHHkv8qEx10QswYMO65rYJ0kUS44jIZK63bCxxjKskROaPfFYWoJ fLIEwZeccyoaTHsDeHLRH/MohiOabRzWZv3tDxkuZxGX0IM0ZmWR+wBXU5wdyqj1W6We /0SPBzDXkXka4t8gmN4f81+B0ld6oR1uJGPIC9ZMIS7cosWlEwYwLw1j+xUEnvqQJGZb AxubgkDZdP1tKauC7huPIVNVBgCCao39kmP91ELhd2yrc9fumDuNcVJJQgaGQEFOatPM WQQWKt2IAWnfhTlCjRU7k2oMF7cm/Z2Z8svZblJJO13Vfp5p824PH8p2qViiOAHNJIqE cz8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eKNe2T3inhmjTnTRQH69fXGTQtYTYo0ljmxCi/IFgUQ=; b=lb8PQl3UWiUcuWtdTYhLC4ok6TDe9+6an/eE+yFCHzwOdzcFDIN5kr/2TEJlq8QR8Q +EG/LeL+TJhVcenhz+4Gi8KwKc0ag/XOwvW5iUDwOiGxMPna2Jp3kqIzANgzJ69gkMTq Qw3TIB/xTMnXk/8emPNJ9hm475C59p/hyILK6s5aJ7ti/QoKHt05HFF1x5bqH2nBitCh pN0+e/hkwWJ87GOiUld2XZtMv6p/Tzc9FB6lpx4EH0IwjsDtxbMF3M95aA2E/BhQnTb4 IgYaf5P9k3eRw6Awl0pdfeJ5lmDMzzWQcyUQh9FeH4VqRYcC+T93mFjqdpX/xIJPq072 6uaQ== X-Gm-Message-State: AOAM530+57cgY5prKYVENdJMHPcc6NOqqlIVbVRbpupsLzYBITnXqQxg dIVGuXPoVXu6IsN+LPv7u2SRG4g5TPjPrqUwcd0W9rNcWLq4/0gF X-Google-Smtp-Source: ABdhPJy/mj61HAP89/rlmXfuwbHVCPyB3Z45JTDE2DnEMVaIx8TurOe1vVum/O6ZXHGgXxsd1jibd2zKhKRCJEw9y/s= X-Received: by 2002:a54:400e:: with SMTP id x14mr7936261oie.21.1610285546115; Sun, 10 Jan 2021 05:32:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vasily Postnicov Date: Sun, 10 Jan 2021 16:32:13 +0300 Message-ID: Subject: Re: DNS using Name Service Switch module and Casper To: Konstantin Belousov Cc: Mark Johnston , freebsd-net@freebsd.org X-Rspamd-Queue-Id: 4DDHnl3C2jz4f52 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 10 Jan 2021 13:32:27 -0000 This is as minimal as I can get. If I knew where to find, what to fix, I would never waste my time seeking for help on mailing lists. Just put FreeBSD in that damn bhyve and play with it, get your hands dirty, you are the developer after all, not me! Your knowledge of FreeBSD is supposedly much greater that mine. For me acceptable solutions are: 1) Remove unsandboxed call to getaddrinfo() from ping. 2) Do not compile with that casper crap which gives false sense of security or whatsoever. I just wanted to help you find a bug where fork() hangs for no reason. So I provided you with all I can get from this situation. Just 20 lines of code to reproduce the bug. And you tell me this is not what you want. So what do you want? A patch that fixes your problem? Sorry for harsh words in your address. But in such situations I question myself should I really report anything and ask anything in FreeBSD community. Btw, if you are still interested, I think I can provide you with the whole bhyve image in which you can reproduce the bug. It contains modified /etc/nsswitch.conf if you cannot change it yourself. =D1=81=D0=B1, 9 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3., 21:47 Konstantin Belousov= : > On Sat, Jan 09, 2021 at 08:25:46PM +0300, Vasily Postnicov wrote: > > Brilliant! It took me almost a day to dive into ZeroMQ to reassure > > myself that there is nothing wrong with it. When I tried to write > > minimal test programs which call fork after pthread_create() in all > > combinations. When I realized that NSS stub module is what I need. > > > > Instructions: > > > > 1) Compile NSS stub module: cc -shared -fPIC -pthread -o > > nss_zerodns.so.1 test.c (Note '.1' at the end). > > 2) Copy nss_zerodns.so.1 to /usr/local/lib > > 3) Apply the patch src_sbin_ping_main.c to ping source code. With this > > patch ping will not quit too early when the initial call to > > getaddrinfo() fails. > > 4) Add stub module to /etc/nsswitch.conf: edit 'hosts' line to be > > 'hosts: files dns zerodns' > > 5) Ping non-existent host, like 'ping foo.bar' > > 6) Ping will hang. The child process which it creates cannot be killed > > even with killall -9 ping > > This is exactly what I do not want. Provide a standalone binary (or > binaries) that can be just run and demonstrate the issue. Without > editing nsswitch.conf or patching ping. > From owner-freebsd-net@freebsd.org Mon Jan 11 03:00:10 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 707A74CA9B7 for ; Mon, 11 Jan 2021 03:00:10 +0000 (UTC) (envelope-from knezour@weboutsourcing.cz) Received: from smtp-out.ujezd.net (smtp-out.ujezd.net [81.90.241.92]) by mx1.freebsd.org (Postfix) with ESMTP id 4DDdjj49VSz4ckW for ; Mon, 11 Jan 2021 03:00:09 +0000 (UTC) (envelope-from knezour@weboutsourcing.cz) Received: by smtp-out.ujezd.net (Postfix, from userid 1001) id 4DDdjg0Q0Wz9s3g; Mon, 11 Jan 2021 04:00:07 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smtp-out.ujezd.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=7.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from [172.23.200.66] (unknown [10.128.99.254]) by smtp-out.ujezd.net (Postfix) with ESMTP id 4DDdjc6zDdz9sFK for ; Mon, 11 Jan 2021 04:00:04 +0100 (CET) To: freebsd-net@freebsd.org From: Ondra Knezour Subject: nfsd doesn't register with rpcbind Message-ID: <9ec68f10-6008-34cd-d89d-2d2b2cf2c0da@weboutsourcing.cz> Date: Mon, 11 Jan 2021 04:00:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020003080204000504070207" X-Rspamd-Queue-Id: 4DDdjj49VSz4ckW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of knezour@weboutsourcing.cz has no SPF policy when checking 81.90.241.92) smtp.mailfrom=knezour@weboutsourcing.cz X-Spamd-Result: default: False [-2.24 / 15.00]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[81.90.241.92:from]; ASN(0.00)[asn:39761, ipnet:81.90.240.0/20, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.49)[-0.494]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[weboutsourcing.cz]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[81.90.241.92:from:127.0.2.255]; R_DKIM_NA(0.00)[]; NEURAL_SPAM_SHORT(0.35)[0.353]; RCVD_IN_DNSWL_NONE(0.00)[81.90.241.92:from]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 11 Jan 2021 03:00:10 -0000 This is a cryptographically signed message in MIME format. --------------ms020003080204000504070207 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, I have longstanding issue with our NFS server, going probably from 10.x=20 release times. Also problematic counterpart (client) has undergone=20 multiple upgrades, but problem persists. Quick intro - NFS server on FreeBSD 12.2 (running there probably for=20 about 3-4 years, hence mentioning 10.x release), couple of clients,=20 mostly Linux. The problematic one is xen on two servers in pool. Now=20 running latest xcp-ng 8.2 (opensource fork of the Citrix product after=20 their licensing changes, based on CentOS 7), also with history of=20 upgrades over the years. The problem is I can mount and use NFS shares from any client, even=20 those xcp-ng servers, but I can't add what xen calls NFS storage=20 repository, which is basically only fancy name for NFS mount with info=20 stored in xen internal configuration database. There are three ways to=20 do it (known to me), xe command line utility, web tool from authors of=20 the mentioned fork named Xen Orchestra and Windows application, which is = remnant of the Citrix era called XenCenter. All three use (AFAIK) some=20 Python scripting on the server (NFS client in this case) to do it. It would be easy to blame this Python part of the problem, but I=20 noticed, that on the FreeBSD side nfsd does not register service with=20 the rpcbind, so I think this may be (at least part of) the problem. I=20 read somewhere, that NFSv4 can work without RPC and in fact, it does for = me, at least partially, but I am not sure what specification says and=20 which part has to be blamed here. So my questions are: 1. Why my nfsd doesn't register with rpcbind? 2. Is this registration somewhat optional at least for NFSv4? 3. How can I get some useful debug info? Using -d options in our servers = startup configuration where it is available doesn't produce much. In the following snippets, 172.22.1.4 or storage-smc is the NFS server=20 and 172.22.1.7 and 172.22.1.27 are the troublesome clients. From the server uname -a FreeBSD storage-smc.ujezd.net 12.2-RELEASE-p1 FreeBSD 12.2-RELEASE-p1 GEN= ERIC amd64 /etc/rc.conf hostname=3D"storage-smc.ujezd.net" cloned_interfaces=3D"vlan1000 vlan1500 vlan2000" ifconfig_vlan1000=3D"inet 172.22.1.4 netmask 255.255.0.0 vlan 1000 vlande= v igb1" ifconfig_vlan2000=3D"inet 10.128.99.4 netmask 255.255.255.0 vlan 2000 vla= ndev igb1" ifconfig_vlan1500=3D"inet 192.168.222.1 netmask 255.255.255.0 vlan 1500 v= landev igb1" ifconfig_igb1=3D"up" nfsuserd_flags=3D"-verbose" defaultrouter=3D"172.22.0.1" sshd_enable=3D"YES" # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable dumpdev=3D"AUTO" zfs_enable=3D"YES" nfsv4_server_enable=3D"YES" nfsuserd_enable=3D"YES" rpcbind_enable=3D"YES" nfs_server_enable=3D"YES" #nfs_server_flags=3D"-h 172.22.1.4" mountd_enable=3D"YES" mountd_flags=3D"-r" kld_list=3D"aesni ipmi" smartd_enable=3D"YES" ntpdate_hosts=3D"10.128.99.95" ntpdate_enable=3D"YES" ntpd_sync_on_start=3D"YES" ntpd_enable=3D"YES" netdata_enable=3D"YES" microcode_update_enable=3D"YES" rpc_lockd_enable=3D"YES" # Run NFS rpc.lockd needed for client/= server. rpc_statd_enable=3D"YES" # Run NFS rpc.statd needed for client/= server. /etc/sysctl.conf vfs.zfs.arc_max=3D"48000000000" vfs.nfsd.server_min_nfsvers=3D4 vfs.nfs.enable_uidtostring=3D1 vfs.nfsd.tcpcachetimeo: 300 vfs.nfsd.tcphighwater: 100000 /etc/exports /zdata/email -maproot=3Droot 10.128.99.79 /zdata/nf -maproot=3Droot 172.22.255.249 /zdata/odkladgalery -maproot=3Droot 172.22.1.10 /zdata/ios -maproot=3Droot 172.22.1.14 /zdata/xen-iso-library -maproot=3Droot 172.22.1.27 /zdata/xen-iso-library -maproot=3Droot 172.22.1.7 /zdata/xen-nfs-storage -maproot=3Droot 172.22.1.27 /zdata/xen-nfs-storage -maproot=3Droot 172.22.1.7 /zdata/servers/xenserver -maproot=3Droot 172.22.1.27 /zdata/servers/xenserver -maproot=3Droot 172.22.1.7 /zdata/servers/xenserver -maproot=3Droot 172.22.1.32 /zdata/virt -maproot=3Droot 172.22.1.27 /zdata/virt -maproot=3Droot 172.22.1.7 /zdata/virt -maproot=3Droot 172.22.1.13 /zdata/virt -maproot=3Droot 172.22.1.2 /zdata/virt -maproot=3Droot -sec=3Dsys 172.22.1.11 V4: / -sec=3Dsys -network 172.22.0.0 -mask 255.255.0.0 V4: / -sec=3Dsys -network 10.128.99.0 -mask 255.255.255.0 rpcinfo -s program version(s) netid(s) service owner= 100000 2,3,4 local,udp6,tcp6,udp,tcp rpcbind super= user 100024 1 tcp,udp,tcp6,udp6 status super= user 100021 4,3,1,0 tcp,udp,tcp6,udp6 nlockmgr super= user 100005 3,1 tcp,udp,tcp6,udp6 mountd super= user And from one of the Linux clients - rpcinfo doesn't show nfsd, but=20 mounts can be probed and mounted without problem. showmount -e 172.22.1.4 Export list for 172.22.1.4: /zdata/virt 172.22.1.11,172.22.1.2,172.22.1.13,172.22.1.7,17= 2.22.1.27 /zdata/xen-nfs-storage 172.22.1.7,172.22.1.27 /zdata/xen-iso-library 172.22.1.7,172.22.1.27 /zdata/odkladgalery 172.22.1.10 /zdata/email 10.128.99.79 /zdata/servers/xenserver 172.22.1.32,172.22.1.7,172.22.1.27 /zdata/ios 172.22.1.14 /zdata/nf 172.22.255.249 rpcinfo -s 172.22.1.4 program version(s) netid(s) service owner= 100000 2,3,4 local,udp6,tcp6,udp,tcp portmapper super= user 100024 1 tcp,udp,tcp6,udp6 status super= user 100021 4,3,1,0 tcp,udp,tcp6,udp6 nlockmgr super= user 100005 3,1 tcp,udp,tcp6,udp6 mountd super= user mount.nfs4 172.22.1.4:/zdata/xen-iso-storage /iso-storage/ mount.nfs4 172.22.1.4:/zdata/xen-iso-library /iso-storage/ mount 172.22.1.4:/zdata/xen-iso-library on /iso-storage type nfs4 (rw,relatime,= vers=3D4.1,rsize=3D131072,wsize=3D131072,namlen=3D255,hard,proto=3Dtcp,ti= meo=3D600,retrans=3D2,sec=3Dsys,clientaddr=3D172.22.1.7,local_lock=3Dnone= ,addr=3D172.22.1.4) 172.22.1.4:/zdata/xen-nfs-storage on /nfs-storage type nfs4 (rw,relatime,= vers=3D4.1,rsize=3D131072,wsize=3D131072,namlen=3D255,hard,proto=3Dtcp,ti= meo=3D600,retrans=3D2,sec=3Dsys,clientaddr=3D172.22.1.7,local_lock=3Dnone= ,addr=3D172.22.1.4) Digging again deeper, I see in log on the client, that missing nfsd in=20 rpcinfo -s call is probably main culprit here. From where came "missing=20 serverpath" error I don't know. Also setting rpcdebug -m [nfs|rpc] -s=20 all (set all debug flags for those two modules) on client yeld nothing=20 at all. Dec 27 22:31:36 xen-2u SM: [25530] _testHost: Testing host/port: storage-= smc.ujezd.net,2049 Dec 27 22:31:36 xen-2u SM: [25530] scanning2 (target=3Dstorage-smc.ujezd.= net) Dec 27 22:31:36 xen-2u SM: [25530] scanning Dec 27 22:31:36 xen-2u SM: [25530] ['/usr/sbin/showmount', '--no-headers'= , '-e', 'storage-smc.ujezd.net'] Dec 27 22:31:36 xen-2u SM: [25530] pread SUCCESS Dec 27 22:31:36 xen-2u SM: [25530] Raising exception [101, The request is= missing the serverpath parameter] Dec 27 22:31:36 xen-2u SM: [25530] lock: released /var/lock/sm/sr Dec 27 22:31:36 xen-2u SM: [25530] ***** generic exception: sr_probe: EXC= EPTION , The request is missing the serverpath para= meter Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py= ", line 110, in run Dec 27 22:31:36 xen-2u SM: [25530] return self._run_locked(sr) Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py= ", line 159, in _run_locked Dec 27 22:31:36 xen-2u SM: [25530] rv =3D self._run(sr, target) Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py= ", line 332, in _run Dec 27 22:31:36 xen-2u SM: [25530] txt =3D sr.probe() Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/NFSSR", line= 164, in probe Dec 27 22:31:36 xen-2u SM: [25530] self.validate_remotepath(True) Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/NFSSR", line= 109, in validate_remotepath Dec 27 22:31:36 xen-2u SM: [25530] raise xs_errors.XenError('ConfigSe= rverPathMissing') Dec 27 22:31:36 xen-2u SM: [25530] Dec 27 22:31:36 xen-2u SM: [25530] ***** NFS VHD: EXCEPTION , The request is missing the serverpath parameter Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py= ", line 378, in run Dec 27 22:31:36 xen-2u SM: [25530] ret =3D cmd.run(sr) Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py= ", line 110, in run Dec 27 22:31:36 xen-2u SM: [25530] return self._run_locked(sr) Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py= ", line 159, in _run_locked Dec 27 22:31:36 xen-2u SM: [25530] rv =3D self._run(sr, target) Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py= ", line 332, in _run Dec 27 22:31:36 xen-2u SM: [25530] txt =3D sr.probe() Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/NFSSR", line= 164, in probe Dec 27 22:31:36 xen-2u SM: [25530] self.validate_remotepath(True) Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/NFSSR", line= 109, in validate_remotepath Dec 27 22:31:36 xen-2u SM: [25530] raise xs_errors.XenError('ConfigSe= rverPathMissing') Dec 27 22:31:36 xen-2u SM: [25530] Dec 27 22:32:02 xen-2u SM: [25713] sr_create {'sr_uuid': '34c61bf5-32d6-a= 0b7-47e7-65209f69ddb9', 'subtask_of': 'DummyRef:|2360ef68-4b8d-4db8-8943-= ec4370f77fa7|SR.create', 'args': ['0'], 'host_ref': 'OpaqueRef:2669e2f3-3= 00e-4748-916f-5811c337e830', 'session_ref': 'OpaqueRef:8f327b0d-9799-420e= -8164-a81353aa99ee', 'device_config': {'location': 'storage-smc.ujezd.net= :/zdata/xen-iso-library', 'type': 'nfs_iso', 'SRmaster': 'true', 'nfsvers= ion': '4'}, 'command': 'sr_create', 'sr_ref': 'OpaqueRef:55ecd645-3bf5-4a= 06-8aae-79443b019047'} Dec 27 22:32:02 xen-2u SM: [25713] _testHost: Testing host/port: storage-= smc.ujezd.net,2049 Dec 27 22:32:02 xen-2u SM: [25713] ['/usr/sbin/rpcinfo', '-s', 'storage-s= mc.ujezd.net'] Dec 27 22:32:02 xen-2u SM: [25713] pread SUCCESS Dec 27 22:32:02 xen-2u SM: [25713] NFS service not ready on server storag= e-smc.ujezd.net And this is part of the code I suspect produces that error RPCINFO_BIN =3D "/usr/sbin/rpcinfo" SHOWMOUNT_BIN =3D "/usr/sbin/showmount" [...] def check_server_service(server): """Ensure NFS service is up and available on the remote server. Returns False if fails to detect service after NFS_SERVICE_RETRY * NFS_SERVICE_WAIT """ retries =3D 0 errlist =3D [errno.EPERM, errno.EPIPE, errno.EIO] while True: try: services =3D util.pread([RPCINFO_BIN, "-s", "%s" % server]) services =3D services.split("\n") for i in range(len(services)): if services[i].find("nfs") > 0: return True except util.CommandException, inst: if not int(inst.code) in errlist: raise util.SMlog("NFS service not ready on server %s" % server) retries +=3D 1 if retries >=3D NFS_SERVICE_RETRY: break time.sleep(NFS_SERVICE_WAIT) return False [...] Best regards Ondra Knezour --------------ms020003080204000504070207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Elektronicky podpis S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EAUwggewMIIFmKADAgECAgIQETANBgkqhkiG9w0BAQ0FADBlMQswCQYDVQQGEwJDWjEXMBUG A1UEYRMOTlRSQ1otNDcxMTQ5ODMxHTAbBgNVBAoMFMSMZXNrw6EgcG/FoXRhLCBzLnAuMR4w HAYDVQQDExVQb3N0U2lnbnVtIFJvb3QgUUNBIDQwHhcNMTgwOTI3MDczOTIzWhcNMzMwOTI3 MDczOTIzWjBpMQswCQYDVQQGEwJDWjEXMBUGA1UEYRMOTlRSQ1otNDcxMTQ5ODMxHTAbBgNV BAoMFMSMZXNrw6EgcG/FoXRhLCBzLnAuMSIwIAYDVQQDExlQb3N0U2lnbnVtIFF1YWxpZmll ZCBDQSA0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAufhybRoyz3Y8nWLACeVN Ui7ZYHNFw9IeBTQLs7f67EqUpVelFU6W+jeOJBQ+HvawXXgNnQRp5IOKF09/YFI6A8/Y79U0 onXCptFbRGPooGGdEbOzSLkBKDDc5AZoGCy2cjuUXHjWveMqC1XaRrtXCG4eVieghMND1Kzb qWCgA1L/LY8AJdkH+iN2Lq7u/YYSBdMuDC+E7YvtfLjbtAP9Wy9ezIf+zDP+2moL9Z1F5/9F 16fTEZuTLqo1gvvR4F+qC+sZUUSh0UZrnjegO6cQWDpJW/gv6R2XGp6hJnqP2JBqaE6qBh7W Az2+SEaUD/VBctDzGGkNA/w4xWh/GHGdaUnAwvPFp2xbvE6Zokmds+iTRvlGYpD4zDb44zAX uybrNlMTMYZvrp0eHlnftrYX7z8K480ksDoumOyf72YuZlo6LxdViayBsCQaogOjd+cQFiAt SnJxRUdIL6lErW/kg4FfAhcZVMuPDdI/oJ9DD7YclnImxxTADFAvtpwDqYmdrmaSTSeHXkid Ki7kX70crKmbuneJjpL7uvVcjIFkBJFmol6fkOcpBd70jmnoFdV5sCzD4lrwcBcxVHet0OPq INSSfMzO1+8TyTKZnoMFnZcWoMm4e51EO3IhoymycPd13I7qGv35YD/SI7zodZuLBT/IUmQV uNwH3j6t4NZEtJUCAwEAAaOCAmQwggJgMIHVBgNVHSAEgc0wgcowgccGBFUdIAAwgb4wgbsG CCsGAQUFBwICMIGuGoGrVGVudG8gY2VydGlmaWthdCBwcm8gZWxla3Ryb25pY2tvdSBwZWNl dCBieWwgdnlkYW4gdiBzb3VsYWR1IHMgbmFyaXplbmltIEVVIGMuIDkxMC8yMDE0LlRoaXMg aXMgYSBjZXJ0aWZpY2F0ZSBmb3IgZWxlY3Ryb25pYyBzZWFsIGFjY29yZGluZyB0byBSZWd1 bGF0aW9uIChFVSkgTm8gOTEwLzIwMTQuMBIGA1UdEwEB/wQIMAYBAf8CAQAwegYIKwYBBQUH AQEEbjBsMDcGCCsGAQUFBzAChitodHRwOi8vY3J0LnBvc3RzaWdudW0uY3ovY3J0L3Bzcm9v dHFjYTQuY3J0MDEGCCsGAQUFBzABhiVodHRwOi8vb2NzcC5wb3N0c2lnbnVtLmN6L09DU1Av UlFDQTQvMA4GA1UdDwEB/wQEAwIBBjAfBgNVHSMEGDAWgBSTGDYfqWlwUTWqTz+sjVB+JgUp CjCBpQYDVR0fBIGdMIGaMDGgL6AthitodHRwOi8vY3JsLnBvc3RzaWdudW0uY3ovY3JsL3Bz cm9vdHFjYTQuY3JsMDKgMKAuhixodHRwOi8vY3JsMi5wb3N0c2lnbnVtLmN6L2NybC9wc3Jv b3RxY2E0LmNybDAxoC+gLYYraHR0cDovL2NybC5wb3N0c2lnbnVtLmV1L2NybC9wc3Jvb3Rx Y2E0LmNybDAdBgNVHQ4EFgQUDyh8PjYAOBBQrj24IZeL92BcYXgwDQYJKoZIhvcNAQENBQAD ggIBABuGFixikXQXOPeKKwO8lrZxavCXzjowiWBDmyBzpvidK0pyiYNnqaYKJ2k99/LX0l8n 8TF0t7XM0TDzZN2uN7pYPDDoLte3oOgIT60yyvAlKDRb2KsWtAMibJJRBCGUUmygB8Dw8mys fE0+TMpJa0WG35IqVKgsP7Z4ZS3rwU0m1TTcE+b5rZ5Nfn5o8qZoz7i7q2H3lpzSyGXBbZPX 3vG5Wa/pZ3qlUDS9bNLtZdMZu77MWi19igZ7Hq4Xp/8OE/zFJEPY7cxW+Wj+DdtCZRsht0e6 03w2FxFFefevehicFYBf6g48TzUxurRvB+15IMnNZzNFXtE502oyb2PGrcOykehW1fAOPVHg fQNFxixyD2S68Lvi/IfKt61X76lIBOt3RnglMHveIxXGjMIpqdwf69ulbOAMuetmPQ8gtvy8 4U6TMGTJRoyefJBv2rqQm91ZDgoLMAs1grUjOOjoZdeVjvutdJD/+zR7P0zdGNZ/Nn9sRlOm uwdlU1Z/udrvco9PtKT8qN5fQfpYY9wYneubRPU4LCwix8FnqhxKcR7mtbVVdEjrDCjD+tEU b27RHSklTyQXUUq1ENa0FplMNs4lneg5wMraIq5RHG3iqAqE9Th5E+s+JyoAZB54p+y8pzdg lEdXY/8+sr8VPUjwtqzmS3EgrGqnbiN1iYeAd1o0MIIITTCCBjWgAwIBAgIEAVK5BjANBgkq hkiG9w0BAQsFADBpMQswCQYDVQQGEwJDWjEXMBUGA1UEYRMOTlRSQ1otNDcxMTQ5ODMxHTAb BgNVBAoMFMSMZXNrw6EgcG/FoXRhLCBzLnAuMSIwIAYDVQQDExlQb3N0U2lnbnVtIFF1YWxp ZmllZCBDQSA0MB4XDTIwMDgzMTA2NDkyMFoXDTIxMDkyMDA2NDkyMFowgaExCzAJBgNVBAYT AkNaMRcwFQYDVQRhEw5OVFJDWi02ODg4NTQ4MjEaMBgGA1UECgwRT25kxZllaiBLbsSbxb5v dXIxCjAIBgNVBAsTATExGjAYBgNVBAMMEU9uZMWZZWogS27Em8W+b3VyMRIwEAYDVQQEDAlL bsSbxb5vdXIxEDAOBgNVBCoMB09uZMWZZWoxDzANBgNVBAUTBlAxODIzNjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANRgqhfMT27FOuxPYzPOFFgHaBG2vpKUVZX751RO//cZ tN4vaRxOnxQUSr/j8M2G+cwkaG+srbm60Bwt+f4t3oKSIaoYjzookXgHiiaG5zggeqNKP8Vk fBHA5LuCCm2vESWqWPaRI3HgdusmVinEvaRi28uQiEoKpcqktqU6YjOGv+B5sgt65TBhenby 2OgjjHKF/Jqqd0GYvkTl0G1s8uVxj69ihrt29AVadp2M3UFrkuSE57WdIhCtTkW/Ik8IH3DP OCUtRMMlehj6QQYWunFFs1yG9pNvG0WZYqmzTvpXVRPR98UKDWdFeUB284S6yeiP4vS3cXAy GzhQZM4f/xkCAwEAAaOCA8IwggO+MD8GA1UdEQQ4MDaBGWtuZXpvdXJAd2Vib3V0c291cmNp bmcuY3qgGQYJKwYBBAHcGQIBoAwTCjExMjg5MTE4NjEwCQYDVR0TBAIwADCCASwGA1UdIASC ASMwggEfMIIBEAYJZ4EGAQQBEYFIMIIBATCB2AYIKwYBBQUHAgIwgcsagchUZW50byBrdmFs aWZpa292YW55IGNlcnRpZmlrYXQgcHJvIGVsZWt0cm9uaWNreSBwb2RwaXMgYnlsIHZ5ZGFu IHYgc291bGFkdSBzIG5hcml6ZW5pbSBFVSBjLiA5MTAvMjAxNC5UaGlzIGlzIGEgcXVhbGlm aWVkIGNlcnRpZmljYXRlIGZvciBlbGVjdHJvbmljIHNpZ25hdHVyZSBhY2NvcmRpbmcgdG8g UmVndWxhdGlvbiAoRVUpIE5vIDkxMC8yMDE0LjAkBggrBgEFBQcCARYYaHR0cDovL3d3dy5w b3N0c2lnbnVtLmN6MAkGBwQAi+xAAQAwgZsGCCsGAQUFBwEDBIGOMIGLMAgGBgQAjkYBATBq BgYEAI5GAQUwYDAuFihodHRwczovL3d3dy5wb3N0c2lnbnVtLmN6L3Bkcy9wZHNfZW4ucGRm EwJlbjAuFihodHRwczovL3d3dy5wb3N0c2lnbnVtLmN6L3Bkcy9wZHNfY3MucGRmEwJjczAT BgYEAI5GAQYwCQYHBACORgEGATB9BggrBgEFBQcBAQRxMG8wOwYIKwYBBQUHMAKGL2h0dHA6 Ly9jcnQucG9zdHNpZ251bS5jei9jcnQvcHNxdWFsaWZpZWRjYTQuY3J0MDAGCCsGAQUFBzAB hiRodHRwOi8vb2NzcC5wb3N0c2lnbnVtLmN6L09DU1AvUUNBNC8wDgYDVR0PAQH/BAQDAgXg MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMB8GA1UdIwQYMBaAFA8ofD42ADgQ UK49uCGXi/dgXGF4MIGxBgNVHR8EgakwgaYwNaAzoDGGL2h0dHA6Ly9jcmwucG9zdHNpZ251 bS5jei9jcmwvcHNxdWFsaWZpZWRjYTQuY3JsMDagNKAyhjBodHRwOi8vY3JsMi5wb3N0c2ln bnVtLmN6L2NybC9wc3F1YWxpZmllZGNhNC5jcmwwNaAzoDGGL2h0dHA6Ly9jcmwucG9zdHNp Z251bS5ldS9jcmwvcHNxdWFsaWZpZWRjYTQuY3JsMB0GA1UdDgQWBBSnhnDHAreHeXLSacaI /Z8kg9/lLjANBgkqhkiG9w0BAQsFAAOCAgEAq5EvldLkudiwRjrWhpSvwZPEHXuh0cwUssY4 PPhJgbFp/LgWtKyN4/pg6o0CgJB7cnNARH5RoBKiZY0EIXhi0ihp6IwspU5MndkCIjjqIAsa rAWeEVGWmy/DyBN72lOWKzDT8FgZUE1yUqOP5UVHo1IMU0R0dmPx9w+K043K1V/7AU5RaX0s TCpDqCuQtpCPTTzeQExjpYRvC1CsEm4LXgXpJtrShrMp1XyHddMnOsUJ8eN96LlwvxdeNrEu Nt+d9WgJQgq5S8VuoLe6YmRiBCHvzDOhmQvi9OTFTB2hwXiin9qXDLhP7aKLVHK7mB91lRhs Z+XLkMT1LdwHnq0urNSY5r6gZH1oGTGaDjHRLPci/evsdck36I1izjWNpgP4a1Ppay/qbwp0 GlcsIvE7x29AiVvsAJM+20D+Vxl5hcID0vdYze62FbuZktGG6u5yikIjVQE0qv9W91LZuAfm X+KUJR6bcCdLwn5oeq15sXKUekuU7QMbMc4U7VFSggxpp9+wjg5JnSN8CTGp1iuCMOVLF6ov n7jM9EW6DQvxngSF4L6Z0GnrbSUf5iOqPg26/Fps3squSEMvO2sNLT3qNCjLEQjNezyctwR+ JWn7WKQ9wl+O4gkYZ++PRo4Yu4GZr5els7L9Zkp4OgwEHfGAvZz5JX/Lh9oi+/vXt022mFcx ggN/MIIDewIBATBxMGkxCzAJBgNVBAYTAkNaMRcwFQYDVQRhEw5OVFJDWi00NzExNDk4MzEd MBsGA1UECgwUxIxlc2vDoSBwb8WhdGEsIHMucC4xIjAgBgNVBAMTGVBvc3RTaWdudW0gUXVh bGlmaWVkIENBIDQCBAFSuQYwDQYJYIZIAWUDBAIBBQCgggHfMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDExMTAzMDAwNlowLwYJKoZIhvcNAQkEMSIE IBMjPun/Nap9o0RIF54ogefhmzF3yh4glnFCpLZd6YqQMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYAGCSsGAQQBgjcQBDFzMHEw aTELMAkGA1UEBhMCQ1oxFzAVBgNVBGETDk5UUkNaLTQ3MTE0OTgzMR0wGwYDVQQKDBTEjGVz a8OhIHBvxaF0YSwgcy5wLjEiMCAGA1UEAxMZUG9zdFNpZ251bSBRdWFsaWZpZWQgQ0EgNAIE AVK5BjCBggYLKoZIhvcNAQkQAgsxc6BxMGkxCzAJBgNVBAYTAkNaMRcwFQYDVQRhEw5OVFJD Wi00NzExNDk4MzEdMBsGA1UECgwUxIxlc2vDoSBwb8WhdGEsIHMucC4xIjAgBgNVBAMTGVBv c3RTaWdudW0gUXVhbGlmaWVkIENBIDQCBAFSuQYwDQYJKoZIhvcNAQEBBQAEggEALpKhJHxa qFOi9H/UiehQpwW5CU7e5hTrknpkMiVCyfwrUrJ0LOhn8uQO85oTbogwGsRB6XDbltsxLRl3 525DVsiLSjBPahG5m/dsL58zd6n1WRESk+3gwH7g/xQc8oRx3HcpVALz/OWVDnbZmtl8Rm5h 48yB7jvBm5Rf60yTgIFbgcaY7vBCBvJ7dt0RkpaNMoc4OFWpSUEmv4eLXC5ZiuRZWgQIFUju 1n9oGm7vxnwhwFKnTBmclOI6tchLR3CZGHEUOTEt78SFsWuuy7ECtKwNetEm64RYxrJnKegD JmtzUME0BNU5lIOAbrb6qTmZ/26v7ACrMI7od+q6WDK+WwAAAAAAAA== --------------ms020003080204000504070207-- From owner-freebsd-net@freebsd.org Mon Jan 11 14:15:25 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 87E094DA45D for ; Mon, 11 Jan 2021 14:15:25 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660063.outbound.protection.outlook.com [40.107.66.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDwhr447Lz3lVl for ; Mon, 11 Jan 2021 14:15:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BOIc5JpN/GHoWtwnFoHIZHJS5z5WRP/c7QsWjIN7kQV9eQgTnIIWK2plWqT62jGSfD0DNLxTIr2EG90cWigp2Tsl5ASuImoreZBvaPRaGyETyal3Nh15aRrebS8KD1QasMmyv67KQE/iNqK3aQvFghACy2BbxT6kItINWptZIE5jXaHPF9PjmF/UdE8XZoYv2NcVEtQSK1cDI7J28lgHipvfOzHQxgn11chVbO4PlxXJHWSSkV+daOAFyAX8FJbWKjGo3TThLgdbOfT53D7jUJJ72kA0zqdb2Gj933qzBqazUjlkomyONZGSd4PE7Ebp0sQ76lnhGrHexXoeWwXiBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/j00vKlU/05xYYsNLnZAmYnfbFVo0vUebCGldQemDBo=; b=RV9S+nsZO11oMCvlF/aPa0m8N1E09djqeRz8sIyEz6GNVYv5G/WvgfWrJ4LtCyMEBFOFjKGo9+EdP64amwrkKAhnoIPYzq+s2fIkNw4s3ddeLMi6xnZbN1cECqORKu7lhzjofoOn2Qs4iCt1uuclOuRNUgH5y8l9IOmV5LSazmL0VD63qB8acQ3TicsD4mjiAgSMSDP4LGrulYpUQ9uUMzmGV9CnFKvfHP6dn/ziF3HPfBVxl5YZnK+3qLErH7bmqtBAxgIrV3cdDeToTVp00oxtO0c0Z2y2OCnktq9OqMEh0gfYq11g+aDLPW1otnTVpGu0mOlyvSvHRkscYAZ45A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/j00vKlU/05xYYsNLnZAmYnfbFVo0vUebCGldQemDBo=; b=MPKuuu45ZL9QXCBKL3sMAo6eVez492NlVdtkFAg34eLEMGvwCZu1pnojhtiqOG+UYJ3+TClZQe6CW4aTAOT0TS1jEG+oTb8fEMDdhEnHy1fYZxbYoj1dI7+cXwy0k1PeJPNFqYxYi78ysJuZ8zTTdWL6DpXqyiC+xLzJGK+hrSdI8ncYdHJZiQgsr1UGF7b+kB3H4P3oMAkemlGFzUQWUcDyDnHYOE0tQnkrvzgqhR81AxFxm+kLoiwddOfTMD2Wcg3GSeOzRqwQG3Y1iBGEjzL1GW+o9flPk2ZT4mNAdkIme65e30OwOHyFyB86C88hddAFk3RSJWoCuIKMP98gfA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 14:15:22 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3742.012; Mon, 11 Jan 2021 14:15:16 +0000 From: Rick Macklem To: Ondra Knezour , "freebsd-net@freebsd.org" Subject: Re: nfsd doesn't register with rpcbind Thread-Topic: nfsd doesn't register with rpcbind Thread-Index: AQHW58Xm2CtSrmTxNUeJpSnNvOnUEqoidXq3 Date: Mon, 11 Jan 2021 14:15:16 +0000 Message-ID: References: <9ec68f10-6008-34cd-d89d-2d2b2cf2c0da@weboutsourcing.cz> In-Reply-To: <9ec68f10-6008-34cd-d89d-2d2b2cf2c0da@weboutsourcing.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9034ee32-1971-48b6-8330-08d8b63b51b7 x-ms-traffictypediagnostic: YQXPR0101MB0968: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4125; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RgEx5Nx3DEttssi4GqwJ6Em81NTrDJKBuB9MnHkMLk3vDaAqyGF3AU7C8ZBAT9lKQXqfDYx1WRRLNVNaW0mmHZyIouzTQt0zuvSFyZR5pJGPNT0Mv9GRNmHhFMUqCVao5puWckgWdxa2l50Pw0ddZr8cbLEGn3z2o6bHMbhpP2wLrjEm4bUJRiSWwjYHXL1JvIGWNaMulKr4reLPdw/MjwsYO7r0dYSzZIsLsdzf7c/2BmxaG3G0yYnVI7VbI6NZuQhb2xQxj4jGSo49wYNblrogTswqm563vSxcLPtPoO5TeivBdK8xo+K/aL//EgB2/hNyjXmRkqE5um0xPRQGTPi2CGyLZTkL+LrHBaCMauP9147tXKPRRkkxvlY50nl+svlBhduO1N4cB84gYMlMXg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(39860400002)(346002)(376002)(366004)(396003)(52536014)(2906002)(8676002)(478600001)(110136005)(76116006)(186003)(86362001)(33656002)(6506007)(7696005)(5660300002)(66556008)(71200400001)(64756008)(66946007)(55016002)(66446008)(66476007)(8936002)(9686003)(316002)(91956017)(83380400001)(786003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?aW2qJJT2Qm4tkZI6jOpgNa+NJmdtSLKF+QIjZitApbANEMSSIZb2HmHN+G?= =?iso-8859-1?Q?q64aGiXVv9xuFt4YPidY99s2wCVdRUkpDJ4yXTn8g7IW3GtByT50J43RRu?= =?iso-8859-1?Q?hX7S0hnRkCGAsrVfEAYtCxmqqdPsxfs4MY2aTdBZ61NSNV26j727dsnZBg?= =?iso-8859-1?Q?ywd2TLmgtz5jt58MV8dy+RkiK6k2gxP/SKC/qt8yGyFO3rlmYajwBDnTFi?= =?iso-8859-1?Q?xiPEw50A+dhFjaGTfpBqLYoWyHHitmHokniyaBp6zYKQavi0Ojk1N5fuIY?= =?iso-8859-1?Q?5Va1AdKEELXzcMQxItnDT+D9QtClIg6UvgPX+V5wUta71wU7xJ5naVVH4A?= =?iso-8859-1?Q?UXpRWHSHBIAe7lIIno6yBxRD+FPqTPoNN5HFJOjT4/5BwXpWEuSEzqcSOG?= =?iso-8859-1?Q?vxmKllW4YZRwqgeDk2Bv3qhBhU3kCV3qN/s4SPV4hYP1soOluJWBW79fJd?= =?iso-8859-1?Q?HSSinE8RBk2fklwMqhvOQAJl2XQRbx2VshQ+HlCc8aJi47I6k8t7e5GiSu?= =?iso-8859-1?Q?TrgNF2T2eA37xmTTlmX39e7NRtalpqQnzmSBQNTLzGGoR0nX6Ww7ZGyyD5?= =?iso-8859-1?Q?lt0rLL8i5ev3e/1JUvoVs5Heui6xfyQN/PKCpA08a9/duhuGTBwgfFfDbF?= =?iso-8859-1?Q?FMkB8EHXHMS3t1OkeuwwWtjSevH5/GDCLuMEREKy+MpkDRVR/s9CJU/rx0?= =?iso-8859-1?Q?l8veKg4RWATjFIimfBLYCES7WUs4d0n+YDDjeGHSgV7EWyUGhf7LrHodwa?= =?iso-8859-1?Q?D9HFhvpvkvlqIsBL7Hk2wZEth2m6wn774nMfzWy4G/u18zzr+tIX1IoEdL?= =?iso-8859-1?Q?2Jm559FPadbVjJMt8UQR5SigXDJjA+P8gRCgyovxFpi8gSF9AGcjyD+f/a?= =?iso-8859-1?Q?IIVrWfwY6qVJlMrXhpDPaJlmtdxQn6HkPT4uxnE5E137Pl13gyQ2TlS1ag?= =?iso-8859-1?Q?SiNbvPsQF2RUtWM7XWgwYrc2UgDNh/8DxGhn3tDQVKZxdGSqJuM0/wWbU8?= =?iso-8859-1?Q?kXb0nS2facKkGDoPHYu3PYhe7ZoCgfd96lbLOKBtlcxG5rjK3PWwlKA8Av?= =?iso-8859-1?Q?yB+WtV9q496By0oH0W/o9Gw=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9034ee32-1971-48b6-8330-08d8b63b51b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2021 14:15:16.2242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IwvuvvaXOVlS2Od8YgD09+4xkQmlLKV3bw5wpF7z3refARf3k7O5u2ohc68K8U6Ihu7xJwxR3oGTt5AAFEq9dw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB0968 X-Rspamd-Queue-Id: 4DDwhr447Lz3lVl X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=MPKuuu45; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.63 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.66.63:from]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[40.107.66.63:from:127.0.2.255]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.63:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.63:from]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 11 Jan 2021 14:15:25 -0000 Ondra Knezour wrote:=0A= [stuff snipped]=0A= >So my questions are:=0A= >1. Why my nfsd doesn't register with rpcbind?=0A= >2. Is this registration somewhat optional at least for NFSv4?=0A= NFSv4 does not use rpcbind. This is generally considered a feature=0A= and not a bug.=0A= --> nfsd will register with rpcbind only if NFSv3 is enabled. (see below)= =0A= =0A= >3. How can I get some useful debug info? Using -d options in our servers= =0A= >startup configuration where it is available doesn't produce much.=0A= [more stuff snipped]=0A= >microcode_update_enable=3D"YES"=0A= >rpc_lockd_enable=3D"YES" # Run NFS rpc.lockd needed for client/s= erver.=0A= >rpc_statd_enable=3D"YES" # Run NFS rpc.statd needed for client/s= erver.=0A= These are sideband protocols used with NFSv3. If all your mounts are NFSv4,= =0A= you don't need them.=0A= =0A= >=0A= >/etc/sysctl.conf=0A= >=0A= >vfs.zfs.arc_max=3D"48000000000"=0A= >vfs.nfsd.server_min_nfsvers=3D4=0A= vfs.nfsd.server_min_nfsvers=3D3=0A= --> Will make it register with rpcbind.=0A= =0A= >vfs.nfs.enable_uidtostring=3D1=0A= You would normally also want=0A= vfs.nfs.enable_stringtouid=3D1=0A= which applies to server as well as=0A= client. If you never run nfsuserd,=0A= then I think it defaults to this anyhow.=0A= =0A= In summary, if you want it to register=0A= with rpcbind, enable NFSv3.=0A= =0A= rick=0A= =0A= vfs.nfsd.tcpcachetimeo: 300=0A= vfs.nfsd.tcphighwater: 100000=0A= =0A= =0A= =0A= /etc/exports=0A= =0A= /zdata/email -maproot=3Droot 10.128.99.79=0A= /zdata/nf -maproot=3Droot 172.22.255.249=0A= /zdata/odkladgalery -maproot=3Droot 172.22.1.10=0A= /zdata/ios -maproot=3Droot 172.22.1.14=0A= /zdata/xen-iso-library -maproot=3Droot 172.22.1.27=0A= /zdata/xen-iso-library -maproot=3Droot 172.22.1.7=0A= /zdata/xen-nfs-storage -maproot=3Droot 172.22.1.27=0A= /zdata/xen-nfs-storage -maproot=3Droot 172.22.1.7=0A= /zdata/servers/xenserver -maproot=3Droot 172.22.1.27=0A= /zdata/servers/xenserver -maproot=3Droot 172.22.1.7=0A= /zdata/servers/xenserver -maproot=3Droot 172.22.1.32=0A= /zdata/virt -maproot=3Droot 172.22.1.27=0A= /zdata/virt -maproot=3Droot 172.22.1.7=0A= /zdata/virt -maproot=3Droot 172.22.1.13=0A= /zdata/virt -maproot=3Droot 172.22.1.2=0A= /zdata/virt -maproot=3Droot -sec=3Dsys 172.22.1.11=0A= V4: / -sec=3Dsys -network 172.22.0.0 -mask 255.255.0.0=0A= V4: / -sec=3Dsys -network 10.128.99.0 -mask 255.255.255.0=0A= =0A= rpcinfo -s=0A= =0A= program version(s) netid(s) service owner= =0A= 100000 2,3,4 local,udp6,tcp6,udp,tcp rpcbind superus= er=0A= 100024 1 tcp,udp,tcp6,udp6 status superus= er=0A= 100021 4,3,1,0 tcp,udp,tcp6,udp6 nlockmgr superus= er=0A= 100005 3,1 tcp,udp,tcp6,udp6 mountd superus= er=0A= =0A= =0A= =0A= And from one of the Linux clients - rpcinfo doesn't show nfsd, but=0A= mounts can be probed and mounted without problem.=0A= =0A= showmount -e 172.22.1.4=0A= Export list for 172.22.1.4:=0A= /zdata/virt 172.22.1.11,172.22.1.2,172.22.1.13,172.22.1.7,172.= 22.1.27=0A= /zdata/xen-nfs-storage 172.22.1.7,172.22.1.27=0A= /zdata/xen-iso-library 172.22.1.7,172.22.1.27=0A= /zdata/odkladgalery 172.22.1.10=0A= /zdata/email 10.128.99.79=0A= /zdata/servers/xenserver 172.22.1.32,172.22.1.7,172.22.1.27=0A= /zdata/ios 172.22.1.14=0A= /zdata/nf 172.22.255.249=0A= =0A= rpcinfo -s 172.22.1.4=0A= program version(s) netid(s) service owner= =0A= 100000 2,3,4 local,udp6,tcp6,udp,tcp portmapper superus= er=0A= 100024 1 tcp,udp,tcp6,udp6 status superus= er=0A= 100021 4,3,1,0 tcp,udp,tcp6,udp6 nlockmgr superus= er=0A= 100005 3,1 tcp,udp,tcp6,udp6 mountd superus= er=0A= =0A= mount.nfs4 172.22.1.4:/zdata/xen-iso-storage /iso-storage/=0A= mount.nfs4 172.22.1.4:/zdata/xen-iso-library /iso-storage/=0A= =0A= mount=0A= 172.22.1.4:/zdata/xen-iso-library on /iso-storage type nfs4 (rw,relatime,ve= rs=3D4.1,rsize=3D131072,wsize=3D131072,namlen=3D255,hard,proto=3Dtcp,timeo= =3D600,retrans=3D2,sec=3Dsys,clientaddr=3D172.22.1.7,local_lock=3Dnone,addr= =3D172.22.1.4)=0A= 172.22.1.4:/zdata/xen-nfs-storage on /nfs-storage type nfs4 (rw,relatime,ve= rs=3D4.1,rsize=3D131072,wsize=3D131072,namlen=3D255,hard,proto=3Dtcp,timeo= =3D600,retrans=3D2,sec=3Dsys,clientaddr=3D172.22.1.7,local_lock=3Dnone,addr= =3D172.22.1.4)=0A= =0A= Digging again deeper, I see in log on the client, that missing nfsd in=0A= rpcinfo -s call is probably main culprit here. From where came "missing=0A= serverpath" error I don't know. Also setting rpcdebug -m [nfs|rpc] -s=0A= all (set all debug flags for those two modules) on client yeld nothing=0A= at all.=0A= =0A= Dec 27 22:31:36 xen-2u SM: [25530] _testHost: Testing host/port: storage-sm= c.ujezd.net,2049=0A= Dec 27 22:31:36 xen-2u SM: [25530] scanning2 (target=3Dstorage-smc.ujezd.ne= t)=0A= Dec 27 22:31:36 xen-2u SM: [25530] scanning=0A= Dec 27 22:31:36 xen-2u SM: [25530] ['/usr/sbin/showmount', '--no-headers', = '-e', 'storage-smc.ujezd.net']=0A= Dec 27 22:31:36 xen-2u SM: [25530] pread SUCCESS=0A= Dec 27 22:31:36 xen-2u SM: [25530] Raising exception [101, The request is m= issing the serverpath parameter]=0A= Dec 27 22:31:36 xen-2u SM: [25530] lock: released /var/lock/sm/sr=0A= Dec 27 22:31:36 xen-2u SM: [25530] ***** generic exception: sr_probe: EXCEP= TION , The request is missing the serverpath paramete= r=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py",= line 110, in run=0A= Dec 27 22:31:36 xen-2u SM: [25530] return self._run_locked(sr)=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py",= line 159, in _run_locked=0A= Dec 27 22:31:36 xen-2u SM: [25530] rv =3D self._run(sr, target)=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py",= line 332, in _run=0A= Dec 27 22:31:36 xen-2u SM: [25530] txt =3D sr.probe()=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/NFSSR", line 1= 64, in probe=0A= Dec 27 22:31:36 xen-2u SM: [25530] self.validate_remotepath(True)=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/NFSSR", line 1= 09, in validate_remotepath=0A= Dec 27 22:31:36 xen-2u SM: [25530] raise xs_errors.XenError('ConfigServ= erPathMissing')=0A= Dec 27 22:31:36 xen-2u SM: [25530]=0A= Dec 27 22:31:36 xen-2u SM: [25530] ***** NFS VHD: EXCEPTION , The request is missing the serverpath parameter=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py",= line 378, in run=0A= Dec 27 22:31:36 xen-2u SM: [25530] ret =3D cmd.run(sr)=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py",= line 110, in run=0A= Dec 27 22:31:36 xen-2u SM: [25530] return self._run_locked(sr)=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py",= line 159, in _run_locked=0A= Dec 27 22:31:36 xen-2u SM: [25530] rv =3D self._run(sr, target)=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/SRCommand.py",= line 332, in _run=0A= Dec 27 22:31:36 xen-2u SM: [25530] txt =3D sr.probe()=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/NFSSR", line 1= 64, in probe=0A= Dec 27 22:31:36 xen-2u SM: [25530] self.validate_remotepath(True)=0A= Dec 27 22:31:36 xen-2u SM: [25530] File "/opt/xensource/sm/NFSSR", line 1= 09, in validate_remotepath=0A= Dec 27 22:31:36 xen-2u SM: [25530] raise xs_errors.XenError('ConfigServ= erPathMissing')=0A= Dec 27 22:31:36 xen-2u SM: [25530]=0A= Dec 27 22:32:02 xen-2u SM: [25713] sr_create {'sr_uuid': '34c61bf5-32d6-a0b= 7-47e7-65209f69ddb9', 'subtask_of': 'DummyRef:|2360ef68-4b8d-4db8-8943-ec43= 70f77fa7|SR.create', 'args': ['0'], 'host_ref': 'OpaqueRef:2669e2f3-300e-47= 48-916f-5811c337e830', 'session_ref': 'OpaqueRef:8f327b0d-9799-420e-8164-a8= 1353aa99ee', 'device_config': {'location': 'storage-smc.ujezd.net:/zdata/xe= n-iso-library', 'type': 'nfs_iso', 'SRmaster': 'true', 'nfsversion': '4'}, = 'command': 'sr_create', 'sr_ref': 'OpaqueRef:55ecd645-3bf5-4a06-8aae-79443b= 019047'}=0A= Dec 27 22:32:02 xen-2u SM: [25713] _testHost: Testing host/port: storage-sm= c.ujezd.net,2049=0A= Dec 27 22:32:02 xen-2u SM: [25713] ['/usr/sbin/rpcinfo', '-s', 'storage-smc= .ujezd.net']=0A= Dec 27 22:32:02 xen-2u SM: [25713] pread SUCCESS=0A= Dec 27 22:32:02 xen-2u SM: [25713] NFS service not ready on server storage-= smc.ujezd.net=0A= =0A= And this is part of the code I suspect produces that error=0A= =0A= RPCINFO_BIN =3D "/usr/sbin/rpcinfo"=0A= SHOWMOUNT_BIN =3D "/usr/sbin/showmount"=0A= [...]=0A= def check_server_service(server):=0A= """Ensure NFS service is up and available on the remote server.=0A= =0A= Returns False if fails to detect service after=0A= NFS_SERVICE_RETRY * NFS_SERVICE_WAIT=0A= """=0A= =0A= retries =3D 0=0A= errlist =3D [errno.EPERM, errno.EPIPE, errno.EIO]=0A= =0A= while True:=0A= try:=0A= services =3D util.pread([RPCINFO_BIN, "-s", "%s" % server])=0A= services =3D services.split("\n")=0A= for i in range(len(services)):=0A= if services[i].find("nfs") > 0:=0A= return True=0A= except util.CommandException, inst:=0A= if not int(inst.code) in errlist:=0A= raise=0A= =0A= util.SMlog("NFS service not ready on server %s" % server)=0A= retries +=3D 1=0A= if retries >=3D NFS_SERVICE_RETRY:=0A= break=0A= =0A= time.sleep(NFS_SERVICE_WAIT)=0A= =0A= return False=0A= =0A= [...]=0A= =0A= Best regards=0A= =0A= Ondra Knezour=0A= =0A= =0A= =0A= From owner-freebsd-net@freebsd.org Mon Jan 11 17:37:26 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 295D44E04FB for ; Mon, 11 Jan 2021 17:37:26 +0000 (UTC) (envelope-from knezour@weboutsourcing.cz) Received: from smtp-out.ujezd.net (smtp-out.ujezd.net [81.90.241.92]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF19x1Sy7z4ZKW for ; Mon, 11 Jan 2021 17:37:24 +0000 (UTC) (envelope-from knezour@weboutsourcing.cz) Received: by smtp-out.ujezd.net (Postfix, from userid 1001) id 4DF19v44L0z9sH7; Mon, 11 Jan 2021 18:37:23 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smtp-out.ujezd.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=7.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from [172.23.200.66] (unknown [10.128.99.254]) by smtp-out.ujezd.net (Postfix) with ESMTP id 4DF19v1Sz3z9sB5; Mon, 11 Jan 2021 18:37:23 +0100 (CET) Subject: Re: nfsd doesn't register with rpcbind To: Rick Macklem , "freebsd-net@freebsd.org" References: <9ec68f10-6008-34cd-d89d-2d2b2cf2c0da@weboutsourcing.cz> From: Ondra Knezour Message-ID: Date: Mon, 11 Jan 2021 18:37:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040709000400030906020706" X-Rspamd-Queue-Id: 4DF19x1Sy7z4ZKW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of knezour@weboutsourcing.cz has no SPF policy when checking 81.90.241.92) smtp.mailfrom=knezour@weboutsourcing.cz X-Spamd-Result: default: False [-2.10 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[81.90.241.92:from]; ASN(0.00)[asn:39761, ipnet:81.90.240.0/20, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[weboutsourcing.cz]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[81.90.241.92:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[81.90.241.92:from]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 11 Jan 2021 17:37:26 -0000 This is a cryptographically signed message in MIME format. --------------ms040709000400030906020706 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: cs Dne 11.01.2021 v 15:15 Rick Macklem napsal(a): > Ondra Knezour wrote: > [stuff snipped] >> So my questions are: >> 1. Why my nfsd doesn't register with rpcbind? >> 2. Is this registration somewhat optional at least for NFSv4? > NFSv4 does not use rpcbind. This is generally considered a feature > and not a bug. > --> nfsd will register with rpcbind only if NFSv3 is enabled. (see belo= w) > [...] > vfs.nfsd.server_min_nfsvers=3D3 > --> Will make it register with rpcbind. Exactly this was needed. Thanks for your insight Rick, I will try to=20 inform authors on the other end that their detection routine fails with=20 NFS 4+. Ondra Knezour --------------ms040709000400030906020706 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Elektronicky podpis S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC EAUwggewMIIFmKADAgECAgIQETANBgkqhkiG9w0BAQ0FADBlMQswCQYDVQQGEwJDWjEXMBUG A1UEYRMOTlRSQ1otNDcxMTQ5ODMxHTAbBgNVBAoMFMSMZXNrw6EgcG/FoXRhLCBzLnAuMR4w HAYDVQQDExVQb3N0U2lnbnVtIFJvb3QgUUNBIDQwHhcNMTgwOTI3MDczOTIzWhcNMzMwOTI3 MDczOTIzWjBpMQswCQYDVQQGEwJDWjEXMBUGA1UEYRMOTlRSQ1otNDcxMTQ5ODMxHTAbBgNV BAoMFMSMZXNrw6EgcG/FoXRhLCBzLnAuMSIwIAYDVQQDExlQb3N0U2lnbnVtIFF1YWxpZmll ZCBDQSA0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAufhybRoyz3Y8nWLACeVN Ui7ZYHNFw9IeBTQLs7f67EqUpVelFU6W+jeOJBQ+HvawXXgNnQRp5IOKF09/YFI6A8/Y79U0 onXCptFbRGPooGGdEbOzSLkBKDDc5AZoGCy2cjuUXHjWveMqC1XaRrtXCG4eVieghMND1Kzb qWCgA1L/LY8AJdkH+iN2Lq7u/YYSBdMuDC+E7YvtfLjbtAP9Wy9ezIf+zDP+2moL9Z1F5/9F 16fTEZuTLqo1gvvR4F+qC+sZUUSh0UZrnjegO6cQWDpJW/gv6R2XGp6hJnqP2JBqaE6qBh7W Az2+SEaUD/VBctDzGGkNA/w4xWh/GHGdaUnAwvPFp2xbvE6Zokmds+iTRvlGYpD4zDb44zAX uybrNlMTMYZvrp0eHlnftrYX7z8K480ksDoumOyf72YuZlo6LxdViayBsCQaogOjd+cQFiAt SnJxRUdIL6lErW/kg4FfAhcZVMuPDdI/oJ9DD7YclnImxxTADFAvtpwDqYmdrmaSTSeHXkid Ki7kX70crKmbuneJjpL7uvVcjIFkBJFmol6fkOcpBd70jmnoFdV5sCzD4lrwcBcxVHet0OPq INSSfMzO1+8TyTKZnoMFnZcWoMm4e51EO3IhoymycPd13I7qGv35YD/SI7zodZuLBT/IUmQV uNwH3j6t4NZEtJUCAwEAAaOCAmQwggJgMIHVBgNVHSAEgc0wgcowgccGBFUdIAAwgb4wgbsG CCsGAQUFBwICMIGuGoGrVGVudG8gY2VydGlmaWthdCBwcm8gZWxla3Ryb25pY2tvdSBwZWNl dCBieWwgdnlkYW4gdiBzb3VsYWR1IHMgbmFyaXplbmltIEVVIGMuIDkxMC8yMDE0LlRoaXMg aXMgYSBjZXJ0aWZpY2F0ZSBmb3IgZWxlY3Ryb25pYyBzZWFsIGFjY29yZGluZyB0byBSZWd1 bGF0aW9uIChFVSkgTm8gOTEwLzIwMTQuMBIGA1UdEwEB/wQIMAYBAf8CAQAwegYIKwYBBQUH AQEEbjBsMDcGCCsGAQUFBzAChitodHRwOi8vY3J0LnBvc3RzaWdudW0uY3ovY3J0L3Bzcm9v dHFjYTQuY3J0MDEGCCsGAQUFBzABhiVodHRwOi8vb2NzcC5wb3N0c2lnbnVtLmN6L09DU1Av UlFDQTQvMA4GA1UdDwEB/wQEAwIBBjAfBgNVHSMEGDAWgBSTGDYfqWlwUTWqTz+sjVB+JgUp CjCBpQYDVR0fBIGdMIGaMDGgL6AthitodHRwOi8vY3JsLnBvc3RzaWdudW0uY3ovY3JsL3Bz cm9vdHFjYTQuY3JsMDKgMKAuhixodHRwOi8vY3JsMi5wb3N0c2lnbnVtLmN6L2NybC9wc3Jv b3RxY2E0LmNybDAxoC+gLYYraHR0cDovL2NybC5wb3N0c2lnbnVtLmV1L2NybC9wc3Jvb3Rx Y2E0LmNybDAdBgNVHQ4EFgQUDyh8PjYAOBBQrj24IZeL92BcYXgwDQYJKoZIhvcNAQENBQAD ggIBABuGFixikXQXOPeKKwO8lrZxavCXzjowiWBDmyBzpvidK0pyiYNnqaYKJ2k99/LX0l8n 8TF0t7XM0TDzZN2uN7pYPDDoLte3oOgIT60yyvAlKDRb2KsWtAMibJJRBCGUUmygB8Dw8mys fE0+TMpJa0WG35IqVKgsP7Z4ZS3rwU0m1TTcE+b5rZ5Nfn5o8qZoz7i7q2H3lpzSyGXBbZPX 3vG5Wa/pZ3qlUDS9bNLtZdMZu77MWi19igZ7Hq4Xp/8OE/zFJEPY7cxW+Wj+DdtCZRsht0e6 03w2FxFFefevehicFYBf6g48TzUxurRvB+15IMnNZzNFXtE502oyb2PGrcOykehW1fAOPVHg fQNFxixyD2S68Lvi/IfKt61X76lIBOt3RnglMHveIxXGjMIpqdwf69ulbOAMuetmPQ8gtvy8 4U6TMGTJRoyefJBv2rqQm91ZDgoLMAs1grUjOOjoZdeVjvutdJD/+zR7P0zdGNZ/Nn9sRlOm uwdlU1Z/udrvco9PtKT8qN5fQfpYY9wYneubRPU4LCwix8FnqhxKcR7mtbVVdEjrDCjD+tEU b27RHSklTyQXUUq1ENa0FplMNs4lneg5wMraIq5RHG3iqAqE9Th5E+s+JyoAZB54p+y8pzdg lEdXY/8+sr8VPUjwtqzmS3EgrGqnbiN1iYeAd1o0MIIITTCCBjWgAwIBAgIEAVK5BjANBgkq hkiG9w0BAQsFADBpMQswCQYDVQQGEwJDWjEXMBUGA1UEYRMOTlRSQ1otNDcxMTQ5ODMxHTAb BgNVBAoMFMSMZXNrw6EgcG/FoXRhLCBzLnAuMSIwIAYDVQQDExlQb3N0U2lnbnVtIFF1YWxp ZmllZCBDQSA0MB4XDTIwMDgzMTA2NDkyMFoXDTIxMDkyMDA2NDkyMFowgaExCzAJBgNVBAYT AkNaMRcwFQYDVQRhEw5OVFJDWi02ODg4NTQ4MjEaMBgGA1UECgwRT25kxZllaiBLbsSbxb5v dXIxCjAIBgNVBAsTATExGjAYBgNVBAMMEU9uZMWZZWogS27Em8W+b3VyMRIwEAYDVQQEDAlL bsSbxb5vdXIxEDAOBgNVBCoMB09uZMWZZWoxDzANBgNVBAUTBlAxODIzNjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANRgqhfMT27FOuxPYzPOFFgHaBG2vpKUVZX751RO//cZ tN4vaRxOnxQUSr/j8M2G+cwkaG+srbm60Bwt+f4t3oKSIaoYjzookXgHiiaG5zggeqNKP8Vk fBHA5LuCCm2vESWqWPaRI3HgdusmVinEvaRi28uQiEoKpcqktqU6YjOGv+B5sgt65TBhenby 2OgjjHKF/Jqqd0GYvkTl0G1s8uVxj69ihrt29AVadp2M3UFrkuSE57WdIhCtTkW/Ik8IH3DP OCUtRMMlehj6QQYWunFFs1yG9pNvG0WZYqmzTvpXVRPR98UKDWdFeUB284S6yeiP4vS3cXAy GzhQZM4f/xkCAwEAAaOCA8IwggO+MD8GA1UdEQQ4MDaBGWtuZXpvdXJAd2Vib3V0c291cmNp bmcuY3qgGQYJKwYBBAHcGQIBoAwTCjExMjg5MTE4NjEwCQYDVR0TBAIwADCCASwGA1UdIASC ASMwggEfMIIBEAYJZ4EGAQQBEYFIMIIBATCB2AYIKwYBBQUHAgIwgcsagchUZW50byBrdmFs aWZpa292YW55IGNlcnRpZmlrYXQgcHJvIGVsZWt0cm9uaWNreSBwb2RwaXMgYnlsIHZ5ZGFu IHYgc291bGFkdSBzIG5hcml6ZW5pbSBFVSBjLiA5MTAvMjAxNC5UaGlzIGlzIGEgcXVhbGlm aWVkIGNlcnRpZmljYXRlIGZvciBlbGVjdHJvbmljIHNpZ25hdHVyZSBhY2NvcmRpbmcgdG8g UmVndWxhdGlvbiAoRVUpIE5vIDkxMC8yMDE0LjAkBggrBgEFBQcCARYYaHR0cDovL3d3dy5w b3N0c2lnbnVtLmN6MAkGBwQAi+xAAQAwgZsGCCsGAQUFBwEDBIGOMIGLMAgGBgQAjkYBATBq BgYEAI5GAQUwYDAuFihodHRwczovL3d3dy5wb3N0c2lnbnVtLmN6L3Bkcy9wZHNfZW4ucGRm EwJlbjAuFihodHRwczovL3d3dy5wb3N0c2lnbnVtLmN6L3Bkcy9wZHNfY3MucGRmEwJjczAT BgYEAI5GAQYwCQYHBACORgEGATB9BggrBgEFBQcBAQRxMG8wOwYIKwYBBQUHMAKGL2h0dHA6 Ly9jcnQucG9zdHNpZ251bS5jei9jcnQvcHNxdWFsaWZpZWRjYTQuY3J0MDAGCCsGAQUFBzAB hiRodHRwOi8vb2NzcC5wb3N0c2lnbnVtLmN6L09DU1AvUUNBNC8wDgYDVR0PAQH/BAQDAgXg MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMB8GA1UdIwQYMBaAFA8ofD42ADgQ UK49uCGXi/dgXGF4MIGxBgNVHR8EgakwgaYwNaAzoDGGL2h0dHA6Ly9jcmwucG9zdHNpZ251 bS5jei9jcmwvcHNxdWFsaWZpZWRjYTQuY3JsMDagNKAyhjBodHRwOi8vY3JsMi5wb3N0c2ln bnVtLmN6L2NybC9wc3F1YWxpZmllZGNhNC5jcmwwNaAzoDGGL2h0dHA6Ly9jcmwucG9zdHNp Z251bS5ldS9jcmwvcHNxdWFsaWZpZWRjYTQuY3JsMB0GA1UdDgQWBBSnhnDHAreHeXLSacaI /Z8kg9/lLjANBgkqhkiG9w0BAQsFAAOCAgEAq5EvldLkudiwRjrWhpSvwZPEHXuh0cwUssY4 PPhJgbFp/LgWtKyN4/pg6o0CgJB7cnNARH5RoBKiZY0EIXhi0ihp6IwspU5MndkCIjjqIAsa rAWeEVGWmy/DyBN72lOWKzDT8FgZUE1yUqOP5UVHo1IMU0R0dmPx9w+K043K1V/7AU5RaX0s TCpDqCuQtpCPTTzeQExjpYRvC1CsEm4LXgXpJtrShrMp1XyHddMnOsUJ8eN96LlwvxdeNrEu Nt+d9WgJQgq5S8VuoLe6YmRiBCHvzDOhmQvi9OTFTB2hwXiin9qXDLhP7aKLVHK7mB91lRhs Z+XLkMT1LdwHnq0urNSY5r6gZH1oGTGaDjHRLPci/evsdck36I1izjWNpgP4a1Ppay/qbwp0 GlcsIvE7x29AiVvsAJM+20D+Vxl5hcID0vdYze62FbuZktGG6u5yikIjVQE0qv9W91LZuAfm X+KUJR6bcCdLwn5oeq15sXKUekuU7QMbMc4U7VFSggxpp9+wjg5JnSN8CTGp1iuCMOVLF6ov n7jM9EW6DQvxngSF4L6Z0GnrbSUf5iOqPg26/Fps3squSEMvO2sNLT3qNCjLEQjNezyctwR+ JWn7WKQ9wl+O4gkYZ++PRo4Yu4GZr5els7L9Zkp4OgwEHfGAvZz5JX/Lh9oi+/vXt022mFcx ggN/MIIDewIBATBxMGkxCzAJBgNVBAYTAkNaMRcwFQYDVQRhEw5OVFJDWi00NzExNDk4MzEd MBsGA1UECgwUxIxlc2vDoSBwb8WhdGEsIHMucC4xIjAgBgNVBAMTGVBvc3RTaWdudW0gUXVh bGlmaWVkIENBIDQCBAFSuQYwDQYJYIZIAWUDBAIBBQCgggHfMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDExMTE3MzcyM1owLwYJKoZIhvcNAQkEMSIE IHJT1/MmZ6VFcXAz6p+H4FDa7Wv7nxhu78ab19Zl2iyLMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYAGCSsGAQQBgjcQBDFzMHEw aTELMAkGA1UEBhMCQ1oxFzAVBgNVBGETDk5UUkNaLTQ3MTE0OTgzMR0wGwYDVQQKDBTEjGVz a8OhIHBvxaF0YSwgcy5wLjEiMCAGA1UEAxMZUG9zdFNpZ251bSBRdWFsaWZpZWQgQ0EgNAIE AVK5BjCBggYLKoZIhvcNAQkQAgsxc6BxMGkxCzAJBgNVBAYTAkNaMRcwFQYDVQRhEw5OVFJD Wi00NzExNDk4MzEdMBsGA1UECgwUxIxlc2vDoSBwb8WhdGEsIHMucC4xIjAgBgNVBAMTGVBv c3RTaWdudW0gUXVhbGlmaWVkIENBIDQCBAFSuQYwDQYJKoZIhvcNAQEBBQAEggEABjyIUsu3 KU43t8teH1BH3VP0nFxEnkzdYkOQ1MoGu4JLrcc0lxSQxHmZqR9g/eBCjjwp7TFDzHUMTw1u ERa3Ba0rmpWAA6vjC4biGwuKb1uYzgY0bgk4E2E7ewDhDTZXehY+KJDbX+3ki6WJRJr0vHyO JXGSKGpirRTvav13wXok0YKSBF4KSkQJfs4mfwFLzArZSmmOkBEPHwzfFDotjvOnvOS9EbAm rxQTSe5QHbUCxyYmsOsHsfzXnsBjUqHqFWjNcndS80LSzZMqx/Ey/Y83LJGammCCyqoAKhXM XTTyabOieuPvkw9JkbuDm2+dkeLumpwH7Zdp2uzgjPSQMQAAAAAAAA== --------------ms040709000400030906020706-- From owner-freebsd-net@freebsd.org Tue Jan 12 02:25:45 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 409014EE0B7 for ; Tue, 12 Jan 2021 02:25:45 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFDvX38Khz3n5H for ; Tue, 12 Jan 2021 02:25:43 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 10C2PQlt021379 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Jan 2021 18:25:26 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 10C2PP7L021378; Mon, 11 Jan 2021 18:25:25 -0800 (PST) (envelope-from jmg) Date: Mon, 11 Jan 2021 18:25:25 -0800 From: John-Mark Gurney To: Lutz Donnerhacke Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD does not reply to IPv6 Neighbor Solicitations Message-ID: <20210112022525.GN31099@funkthat.com> Mail-Followup-To: Lutz Donnerhacke , freebsd-net@freebsd.org References: <20210105031528.GA91534@admin.sibptus.ru> <00a101d6e33b$96edf0c0$c4c9d240$@donnerhacke.de> <20210105104650.GA7688@admin.sibptus.ru> <00b601d6e35a$115a4a20$340ede60$@donnerhacke.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b601d6e35a$115a4a20$340ede60$@donnerhacke.de> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 11 Jan 2021 18:25:26 -0800 (PST) X-Rspamd-Queue-Id: 4DFDvX38Khz3n5H X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 12 Jan 2021 02:25:45 -0000 Lutz Donnerhacke wrote this message on Tue, Jan 05, 2021 at 12:58 +0100: > > > May you be able to capture the icmp6 traffic of this interface with > > > respect to ND? I'm really interested in seeing, that the box does > > > not respond to a given NS query. > > > > Here you are http://admin.sibptus.ru/~vas/nd1.pcapng > > The device, where the capture was taken does not respond tot he NS packet. > This might be caused by: > a) the device has a different configured IP address, than requested > b) the network card does not listen to the multicast group, which is > used by the request (you see it only due to the promisc mode of the > capture). But this is unlikely (due to the promisc mode) > c) your system is broken I have some test scripts where something similar to this happens. I tcpdump shows the request coming into the FreeBSD box (in this case, 13-current main-c255640-gc38e59ce1b0), addressed to the IPv6 of the box, and FreeBSD failing to respond w/ an answer for it's own IP... This is inconsistent and hard to reproduce, but it does happen with somewhat regularity. This is from the host w/ ipv6 address fc00:b5d:41c:7e37::c43c: 02:11:53.065550 IP6 :: > ff02::1:ff00:7e37: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::7e37, length 32 02:11:53.069274 IP6 :: > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 02:11:54.639001 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 02:11:55.659956 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 02:11:56.667880 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 and this is from the host w/ ipv6 address fc00:b5d:41c:7e37::7e37: 02:11:53.065345 IP6 :: > ff02::1:ff00:7e37: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::7e37, length 32 02:11:54.638742 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 02:11:55.658801 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 02:11:56.667187 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 So, these captures are from the same host, but w/ the two interfaces in different vnet jails, but wired back to back, so the time stamps came from same clock, so can give you close to absolute ordering between the two captures... This is pretty much, bring up interface, configure a/ ipv6 addresses, and then ping the address, and fail after a couple tries. I'm not sure why the 7e37 host didn't receive c43c's hosts broadcast announcing their address, but other times, it will properly respond, for example: 05:08:32.158342 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 05:08:32.158377 IP6 fc00:b5d:41c:7e37::c43c > fc00:b5d:41c:7e37::7e37: ICMP6, neighbor advertisement, tgt is fc00:b5d:41c:7e37::c43c, length 32 05:08:32.215624 IP6 fc00:b5d:41c:7e37::7e37 > fc00:b5d:41c:7e37::c43c: ICMP6, echo request, seq 0, length 16 05:08:32.215646 IP6 fc00:b5d:41c:7e37::c43c > fc00:b5d:41c:7e37::7e37: ICMP6, echo reply, seq 0, length 16 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@freebsd.org Tue Jan 12 13:34:17 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 01CA64D85F8 for ; Tue, 12 Jan 2021 13:34:17 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward103p.mail.yandex.net (forward103p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:106]) (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 4DFWkv5dgGz3GXp for ; Tue, 12 Jan 2021 13:34:15 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from myt5-a43f74ee162a.qloud-c.yandex.net (myt5-a43f74ee162a.qloud-c.yandex.net [IPv6:2a02:6b8:c12:3e14:0:640:a43f:74ee]) by forward103p.mail.yandex.net (Yandex) with ESMTP id 42FED18C007B; Tue, 12 Jan 2021 16:34:11 +0300 (MSK) Received: from myt2-accb38a5c431.qloud-c.yandex.net (myt2-accb38a5c431.qloud-c.yandex.net [2a02:6b8:c00:2e9b:0:640:accb:38a5]) by myt5-a43f74ee162a.qloud-c.yandex.net (mxback/Yandex) with ESMTP id JONTfyXDj8-YAGGr0oA; Tue, 12 Jan 2021 16:34:10 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1610458451; bh=DmFDowREJcC239JhN7abJNIi932FZanagnKuQib6sPM=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=Auv8ERlDW124ww58b6XJG8379LrMor6NZj2tlXRHYEat/TgFuJ/S4r9jW3KMgvaXE bfLThALPD0wxwwQpQrK8dqz9W/0HpkUuiRwTDFNBSW7Eh1fp9vzkqC0/MVz7zCKPy6 lBnmPj9QAxBZx6nFysEhBjonQ4bU9ZKC4EoFKFtA= Received: by myt2-accb38a5c431.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id Nan9wQT4CG-YAHelBaW; Tue, 12 Jan 2021 16:34:10 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: FreeBSD does not reply to IPv6 Neighbor Solicitations To: Lutz Donnerhacke , freebsd-net@freebsd.org References: <20210105031528.GA91534@admin.sibptus.ru> <00a101d6e33b$96edf0c0$c4c9d240$@donnerhacke.de> <20210105104650.GA7688@admin.sibptus.ru> <00b601d6e35a$115a4a20$340ede60$@donnerhacke.de> <20210112022525.GN31099@funkthat.com> From: "Andrey V. Elsukov" Message-ID: <95be49e2-56cc-cf3f-3515-8f13f14ddbad@yandex.ru> Date: Tue, 12 Jan 2021 16:33:17 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20210112022525.GN31099@funkthat.com> Content-Type: multipart/mixed; boundary="------------120027B1794E44F3043DF14A" Content-Language: en-US X-Rspamd-Queue-Id: 4DFWkv5dgGz3GXp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=Auv8ERlD; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 2a02:6b8:0:1472:2741:0:8b7:106 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yandex.ru]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1000::/52]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[yandex.ru:+]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; RCVD_IN_DNSWL_LOW(-0.10)[2a02:6b8:0:1472:2741:0:8b7:106:from]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a02:6b8:0:1472:2741:0:8b7:106:from]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; SPAMHAUS_ZRD(0.00)[2a02:6b8:0:1472:2741:0:8b7:106:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 12 Jan 2021 13:34:17 -0000 This is a multi-part message in MIME format. --------------120027B1794E44F3043DF14A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 12.01.2021 05:25, John-Mark Gurney wrote: >> The device, where the capture was taken does not respond tot he NS packet. >> This might be caused by: >> a) the device has a different configured IP address, than requested >> b) the network card does not listen to the multicast group, which is >> used by the request (you see it only due to the promisc mode of the >> capture). But this is unlikely (due to the promisc mode) >> c) your system is broken > > I have some test scripts where something similar to this happens. > > I tcpdump shows the request coming into the FreeBSD box (in this case, > 13-current main-c255640-gc38e59ce1b0), addressed to the IPv6 of the > box, and FreeBSD failing to respond w/ an answer for it's own IP... > > This is inconsistent and hard to reproduce, but it does happen with > somewhat regularity. Hi, when this will happen again, it would be nice to make sure that NS packets hit the IP stack. E.g. with attached dtrace script. Also net.inet6.icmp6.nd6_debug variable should be set to see error messages from ND code. If it doesn't show expected info, this means that packets don't hit IP stack. Probably some multicast related problem. In this case it could be useful to obtain output of ifmcstat(8). -- WBR, Andrey V. Elsukov --------------120027B1794E44F3043DF14A Content-Type: text/plain; charset=UTF-8; name="nd6.d.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nd6.d.txt" IyEvdXNyL3NiaW4vZHRyYWNlIC1zCgpmYnQ6Om5kNl9uc19pbnB1dDplbnRyeQp7CglpcCA9 IChzdHJ1Y3QgaXA2X2hkciAqKWFyZ3NbMF0tPm1fZGF0YTsKCW5kID0gKHN0cnVjdCBuZF9u ZWlnaGJvcl9zb2xpY2l0ICopYXJnc1swXS0+bV9kYXRhICsgYXJnc1sxXTsKCglwcmludGYo IiVzOiBOUyBmcm9tICVzIHRvICVzLCB0YXJnZXQgJXMiLAoJICAgIHN0cmluZ29mKGFyZ3Nb MF0tPm1fcGt0aGRyLnJjdmlmLT5pZl94bmFtZSksCgkgICAgaW5ldF9udG9hNigmaXAtPmlw Nl9zcmMpLCBpbmV0X250b2E2KCZpcC0+aXA2X2RzdCksCgkgICAgaW5ldF9udG9hNigmbmQt Pm5kX25zX3RhcmdldCkpOwp9CgpmYnQ6Om5kNl9uYV9vdXRwdXRfZmliOmVudHJ5CnsKCglw cmludGYoIiVzOiBOQSB0byAlcywgdGFyZ2V0ICVzIiwKCSAgICBzdHJpbmdvZihhcmdzWzBd LT5pZl94bmFtZSksIGluZXRfbnRvYTYoYXJnc1sxXSksCgkgICAgaW5ldF9udG9hNihhcmdz WzJdKSk7Cn0K --------------120027B1794E44F3043DF14A-- From owner-freebsd-net@freebsd.org Tue Jan 12 21:37:23 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1A6694E7009 for ; Tue, 12 Jan 2021 21:37:23 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFkSK6NVhz4hgp for ; Tue, 12 Jan 2021 21:37:21 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 10CLb98I059334 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Jan 2021 13:37:10 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 10CLb7D4059332; Tue, 12 Jan 2021 13:37:07 -0800 (PST) (envelope-from jmg) Date: Tue, 12 Jan 2021 13:37:07 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Cc: Lutz Donnerhacke , freebsd-net@freebsd.org Subject: Re: FreeBSD does not reply to IPv6 Neighbor Solicitations Message-ID: <20210112213707.GP31099@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , Lutz Donnerhacke , freebsd-net@freebsd.org References: <20210105031528.GA91534@admin.sibptus.ru> <00a101d6e33b$96edf0c0$c4c9d240$@donnerhacke.de> <20210105104650.GA7688@admin.sibptus.ru> <00b601d6e35a$115a4a20$340ede60$@donnerhacke.de> <20210112022525.GN31099@funkthat.com> <95be49e2-56cc-cf3f-3515-8f13f14ddbad@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95be49e2-56cc-cf3f-3515-8f13f14ddbad@yandex.ru> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 12 Jan 2021 13:37:10 -0800 (PST) X-Rspamd-Queue-Id: 4DFkSK6NVhz4hgp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yandex.ru]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-net]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 12 Jan 2021 21:37:23 -0000 Andrey V. Elsukov wrote this message on Tue, Jan 12, 2021 at 16:33 +0300: > On 12.01.2021 05:25, John-Mark Gurney wrote: > >> The device, where the capture was taken does not respond tot he NS packet. > >> This might be caused by: > >> a) the device has a different configured IP address, than requested > >> b) the network card does not listen to the multicast group, which is > >> used by the request (you see it only due to the promisc mode of the > >> capture). But this is unlikely (due to the promisc mode) > >> c) your system is broken > > > > I have some test scripts where something similar to this happens. > > > > I tcpdump shows the request coming into the FreeBSD box (in this case, > > 13-current main-c255640-gc38e59ce1b0), addressed to the IPv6 of the > > box, and FreeBSD failing to respond w/ an answer for it's own IP... > > > > This is inconsistent and hard to reproduce, but it does happen with > > somewhat regularity. > > when this will happen again, it would be nice to make sure that NS > packets hit the IP stack. E.g. with attached dtrace script. Ok, I ran the dtrace script when I reproduced the problem, and it did not produce any output. Here are the steps that I use to setup the interfaces for this test, which seems to trigger it... This is on a single machine, usings the on board bge0 and a USB ure... Each interface is put in their own vnet jail... I've attached the script, just need to init the jails, then run the test a couple of times: sh testinterfaces.sh init ue0 bge0 sh testinterfaces.sh csum ue0 bge0 sh testinterfaces.sh csum ue0 bge0 When it fails, you'll see something like: [...] ping FAILED on -rxcsum6!!!! 27018 27019 test failed, data in /tmp/testiface.moLZMgFH csumtest failed. the numbers are the pid's of the tcpdumps that were run... There are also pcaps of the two sides in the directory... These are effectively what the script does: 1) start w/ both interfaces in down state (they have ipv6 addresses set from previous run) 2) configure csum flags on ure (in this case, -rxcsum6) 3) verify that flag is cleared 4) disable all csum flags on bge0 (-txcsum -rxcsum -txcsum6 -rxcsum6) 5) verify that -txcsum and -rxcsum on bge0 (just realized this is a bug in my script that I don't verify the ipv6 versions of the flag) 6) sleep for .5 seconds 7) bring up ure 8) bring up bge0 9) configure inet6 addresses on ure and bge (duplicating the addresses already configured) 10) wait for both interfaces to have link, AND the inet6 addresses to not be in tentative state 11) sleep .5 12) run ping, and see it fail due to the ND problem I ran the dtrace script in the host system, which iirc, should be fine. If you enable the removal of the inet6 addresses in cleaniface, this error does not seem to trigger... > Also net.inet6.icmp6.nd6_debug variable should be set to see error > messages from ND code. I set it in the jail, and did not see any messages... I reset the interface, and was able to see the messages when it "worked", so it looks like the packets aren't hitting the ip stack properly... > If it doesn't show expected info, this means that packets don't hit IP > stack. Probably some multicast related problem. In this case it could be > useful to obtain output of ifmcstat(8). So, the output of ifmcstat when it isn't working: root@test:~ # jexec checkjail ifmcstat lo0: inet6 fe80::1%lo0 scopeid 0x1 sysctl net.inet6.mld.ifinfo: No such file or directory group ff01::1%lo0 scopeid 0x1 mode exclude group ff02::1%lo0 scopeid 0x1 mode exclude group ff02::1:ff00:1%lo0 scopeid 0x1 mode exclude bge0: inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 group ff01::1%bge0 scopeid 0x2 mode exclude mcast-macaddr 33:33:00:00:00:01 group ff02::1%bge0 scopeid 0x2 mode exclude mcast-macaddr 33:33:00:00:00:01 group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude mcast-macaddr 33:33:ff:xx:xx:xx I'm not sure why there's an error on net.inet6.mld.ifinfo, as both my kernel and userland should be in sync, as of Jan 9th... so, I made things works, and ran ifmcstat again, and this time it has an additional group in the output: [...] bge0: inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 group ff02::1:ff00:c43c%bge0 scopeid 0x2 mode exclude mcast-macaddr 33:33:ff:00:c4:3c group ff01::1%bge0 scopeid 0x2 mode exclude mcast-macaddr 33:33:00:00:00:01 group ff02::1%bge0 scopeid 0x2 mode exclude mcast-macaddr 33:33:00:00:00:01 group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude mcast-macaddr 33:33:ff:xx:xx:xx and the tcpdump output: 21:10:53.938655 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 21:10:55.001428 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 In this case, the interface that is having issues is bge0, so it's a "real" NIC and should be well supported... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@freebsd.org Wed Jan 13 08:43:34 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BE2794D51AA for ; Wed, 13 Jan 2021 08:43:34 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward105p.mail.yandex.net (forward105p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:108]) (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 4DG1F13dhMz3rM1 for ; Wed, 13 Jan 2021 08:43:33 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from myt6-2cec5828668a.qloud-c.yandex.net (myt6-2cec5828668a.qloud-c.yandex.net [IPv6:2a02:6b8:c12:4019:0:640:2cec:5828]) by forward105p.mail.yandex.net (Yandex) with ESMTP id 027F44D410C2; Wed, 13 Jan 2021 11:43:30 +0300 (MSK) Received: from myt2-accb38a5c431.qloud-c.yandex.net (myt2-accb38a5c431.qloud-c.yandex.net [2a02:6b8:c00:2e9b:0:640:accb:38a5]) by myt6-2cec5828668a.qloud-c.yandex.net (mxback/Yandex) with ESMTP id GI8LSeB4Zu-hTGqYxJT; Wed, 13 Jan 2021 11:43:29 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1610527409; bh=VKMVf4jjWPKIh3rU0KU0uAIo9umTpp8BBXMnf0dNAA4=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=wdk4c9tQPG4VldxnO60jcejYlYdedr32LX5FmxQ3YRAZGfOay/F1BEDFps9EJBQbm cOqY12pw7IOHcvQ2w9xjBkm/z9pnRQjOhd+mMZtqNREHBLS3I8vGPnXdxREuVWnM2j hudWReHvLiO9PLghU11BXe6mveVtY2JujIoNEdXk= Received: by myt2-accb38a5c431.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id tMVCrdb9jC-hTH0kTo8; Wed, 13 Jan 2021 11:43:29 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: FreeBSD does not reply to IPv6 Neighbor Solicitations To: Lutz Donnerhacke , freebsd-net@freebsd.org, Hans Petter Selasky References: <20210105031528.GA91534@admin.sibptus.ru> <00a101d6e33b$96edf0c0$c4c9d240$@donnerhacke.de> <20210105104650.GA7688@admin.sibptus.ru> <00b601d6e35a$115a4a20$340ede60$@donnerhacke.de> <20210112022525.GN31099@funkthat.com> <95be49e2-56cc-cf3f-3515-8f13f14ddbad@yandex.ru> <20210112213707.GP31099@funkthat.com> From: "Andrey V. Elsukov" Message-ID: <065eaff7-35bd-0cd3-f68f-849be2178574@yandex.ru> Date: Wed, 13 Jan 2021 11:42:32 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20210112213707.GP31099@funkthat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DG1F13dhMz3rM1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=wdk4c9tQ; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 2a02:6b8:0:1472:2741:0:8b7:108 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-3.52 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yandex.ru]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1000::/52]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[yandex.ru:+]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; NEURAL_HAM_SHORT(-0.42)[-0.420]; RCVD_IN_DNSWL_LOW(-0.10)[2a02:6b8:0:1472:2741:0:8b7:108:from]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a02:6b8:0:1472:2741:0:8b7:108:from]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yandex.ru:dkim]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2a02:6b8:0:1472:2741:0:8b7:108:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 13 Jan 2021 08:43:34 -0000 On 13.01.2021 00:37, John-Mark Gurney wrote: >> when this will happen again, it would be nice to make sure that NS >> packets hit the IP stack. E.g. with attached dtrace script. > > Ok, I ran the dtrace script when I reproduced the problem, and it did > not produce any output. > > These are effectively what the script does: > 9) configure inet6 addresses on ure and bge (duplicating the addresses > already configured) Does it mean that you just reconfigure address without removing it? It looks like the problem, that was discussed here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233535 > bge0: > inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 > group ff01::1%bge0 scopeid 0x2 mode exclude > mcast-macaddr 33:33:00:00:00:01 > group ff02::1%bge0 scopeid 0x2 mode exclude > mcast-macaddr 33:33:00:00:00:01 > group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude > mcast-macaddr 33:33:ff:xx:xx:xx > > so, I made things works, and ran ifmcstat again, and this time it has > an additional group in the output: > [...] > bge0: > inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 > group ff02::1:ff00:c43c%bge0 scopeid 0x2 mode exclude > mcast-macaddr 33:33:ff:00:c4:3c > group ff01::1%bge0 scopeid 0x2 mode exclude > mcast-macaddr 33:33:00:00:00:01 > group ff02::1%bge0 scopeid 0x2 mode exclude > mcast-macaddr 33:33:00:00:00:01 > group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude > mcast-macaddr 33:33:ff:xx:xx:xx > > and the tcpdump output: > 21:10:53.938655 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 > 21:10:55.001428 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 Since ff02::1:ff00:c43c%bge0 is not configured in first case, IP stack just ignores NS messages and they don't hit ND6 code. In the PR 233535 the problem was reproducible with MLDv1, so if you disable MLDv2 will it work (to reduce possible scope of problematic code)? net.inet6.mld.v2enable=0 -- WBR, Andrey V. Elsukov From owner-freebsd-net@freebsd.org Thu Jan 14 01:59:41 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C66F4D0568 for ; Thu, 14 Jan 2021 01:59:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGSDX1NMPz4b0q for ; Thu, 14 Jan 2021 01:59:39 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 10E1xLfF013673 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 Jan 2021 17:59:21 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 10E1xH9H013671; Wed, 13 Jan 2021 17:59:17 -0800 (PST) (envelope-from jmg) Date: Wed, 13 Jan 2021 17:59:17 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" Cc: Lutz Donnerhacke , freebsd-net@freebsd.org, Hans Petter Selasky Subject: Re: FreeBSD does not reply to IPv6 Neighbor Solicitations Message-ID: <20210114015917.GR31099@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , Lutz Donnerhacke , freebsd-net@freebsd.org, Hans Petter Selasky References: <20210105031528.GA91534@admin.sibptus.ru> <00a101d6e33b$96edf0c0$c4c9d240$@donnerhacke.de> <20210105104650.GA7688@admin.sibptus.ru> <00b601d6e35a$115a4a20$340ede60$@donnerhacke.de> <20210112022525.GN31099@funkthat.com> <95be49e2-56cc-cf3f-3515-8f13f14ddbad@yandex.ru> <20210112213707.GP31099@funkthat.com> <065eaff7-35bd-0cd3-f68f-849be2178574@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <065eaff7-35bd-0cd3-f68f-849be2178574@yandex.ru> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Wed, 13 Jan 2021 17:59:21 -0800 (PST) X-Rspamd-Queue-Id: 4DGSDX1NMPz4b0q X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [0.20 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yandex.ru]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-net]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 01:59:41 -0000 Andrey V. Elsukov wrote this message on Wed, Jan 13, 2021 at 11:42 +0300: > On 13.01.2021 00:37, John-Mark Gurney wrote: > >> when this will happen again, it would be nice to make sure that NS > >> packets hit the IP stack. E.g. with attached dtrace script. > > > > Ok, I ran the dtrace script when I reproduced the problem, and it did > > not produce any output. > > > > These are effectively what the script does: > > 9) configure inet6 addresses on ure and bge (duplicating the addresses > > already configured) > > Does it mean that you just reconfigure address without removing it? It > looks like the problem, that was discussed here > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233535 Yeah, I guess it is the same... > > bge0: > > inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 > > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 > > group ff01::1%bge0 scopeid 0x2 mode exclude > > mcast-macaddr 33:33:00:00:00:01 > > group ff02::1%bge0 scopeid 0x2 mode exclude > > mcast-macaddr 33:33:00:00:00:01 > > group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude > > mcast-macaddr 33:33:ff:xx:xx:xx > > > > so, I made things works, and ran ifmcstat again, and this time it has > > an additional group in the output: > > [...] > > bge0: > > inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 > > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 > > group ff02::1:ff00:c43c%bge0 scopeid 0x2 mode exclude > > mcast-macaddr 33:33:ff:00:c4:3c > > group ff01::1%bge0 scopeid 0x2 mode exclude > > mcast-macaddr 33:33:00:00:00:01 > > group ff02::1%bge0 scopeid 0x2 mode exclude > > mcast-macaddr 33:33:00:00:00:01 > > group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude > > mcast-macaddr 33:33:ff:xx:xx:xx > > > > and the tcpdump output: > > 21:10:53.938655 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 > > 21:10:55.001428 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 > > Since ff02::1:ff00:c43c%bge0 is not configured in first case, IP stack > just ignores NS messages and they don't hit ND6 code. > > In the PR 233535 the problem was reproducible with MLDv1, so if you > disable MLDv2 will it work (to reduce possible scope of problematic code)? > > net.inet6.mld.v2enable=0 I just tested this, and it does not fix the problem for me. Do I need to reboot or something? If I set it to 0, the bug still appears, and also the ifmcstat has the line: mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 is there something else that needs to be done to disable mldv2? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@freebsd.org Thu Jan 14 15:56:50 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 158484E69C2 for ; Thu, 14 Jan 2021 15:56:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGppT22dSz4Y0N for ; Thu, 14 Jan 2021 15:56:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd35.google.com with SMTP id e22so12075121iom.5 for ; Thu, 14 Jan 2021 07:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=ODyFWcQAslmlOhizW7J0CVRE3igoXu3Id8YzybxqRAs=; b=jELDQM+ZLpzj0+ocIXdRJydpoLefjjx3IzVXPWgMwE7waZ+1W8KN3gmilla82zEcOR Ecgh9mP7uPWYO17I/IDRpdThgYIP3+BURHlJxy2AlBRau5WzHLL/uxzk2Vb3EeU2tHzT szuZ6GnZ01Y3LFYhoDafmOARCGN2+K+MGWndvsaI8yg5rTOMsvWav4q/RRInaM4vwPUj aq1AJQ7Knoy3cFOiYKCYHybjVYwSxkpia6mI1Deiko6pUVSd4SeocDoWIDySvnt1cr9n 9X0xa+t3DLqGmHKWQsjEFh74kW8H/xYpK+Ai0SxMvHJaye/6waoEwnTm2ImJfN0mlwAy XRtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=ODyFWcQAslmlOhizW7J0CVRE3igoXu3Id8YzybxqRAs=; b=b2aSlYGyHhzs22oou+led0vRYuFqfjCXKJFEIhTIkWF65+TxEFw8Txz5b8iagoYvjh F/B2HyOX5P3gWHrFZSzDkpjFPMnvzpR5SjeMpNt2nrbQ1YfWIvPsAPQ/zj20X7O6Vzna Qe9QQZSf/7/qMYtTpyJ05jEtfQqAbsupKkiac9A/roQTIgSoaxTZGvIHL+OHdZv6+5h1 /JvaOF5ga/3/GwLHdmLFAZVXyKLjzZ6Kx6TkQCkTWEfeHgcBabNLksgRAusGeJztuKxa e7SCn6B4tWXK1XO5AAOCp8KYnokmXGmlKvBuP7eYbIrqo8LXnKOi3qZWidi1qnwpRwJJ IY3A== X-Gm-Message-State: AOAM530mRaBIvvagKppQG42VQnqqps6dm9k3soaGdecSeFmhQWtz87FC x6RcQVN85Su8S8gBL1cv8/M= X-Google-Smtp-Source: ABdhPJwf9WlaGj9JjnTgW2rPedCNuSujTOtBa/vhrVNSiwnu7fodhKjn7L7E/uO+gsiGRZZtJwYUcQ== X-Received: by 2002:a05:6638:d8a:: with SMTP id l10mr1296575jaj.2.1610639807785; Thu, 14 Jan 2021 07:56:47 -0800 (PST) Received: from raichu ([142.126.164.150]) by smtp.gmail.com with ESMTPSA id w4sm344549iop.28.2021.01.14.07.56.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Jan 2021 07:56:46 -0800 (PST) Sender: Mark Johnston Date: Thu, 14 Jan 2021 10:56:45 -0500 From: Mark Johnston To: Vasily Postnicov Cc: freebsd-net@freebsd.org Subject: Re: DNS using Name Service Switch module and Casper Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4DGppT22dSz4Y0N X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jELDQM+Z; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::d35 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-0.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::d35:from]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::d35:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d35:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 15:56:50 -0000 On Sun, Jan 10, 2021 at 04:32:13PM +0300, Vasily Postnicov wrote: > This is as minimal as I can get. If I knew where to find, what to fix, I > would never waste my time seeking for help on mailing lists. > > Just put FreeBSD in that damn bhyve and play with it, get your hands dirty, > you are the developer after all, not me! Your knowledge of FreeBSD is > supposedly much greater that mine. > > For me acceptable solutions are: > 1) Remove unsandboxed call to getaddrinfo() from ping. > 2) Do not compile with that casper crap which gives false sense of security > or whatsoever. > > I just wanted to help you find a bug where fork() hangs for no reason. So I > provided you with all I can get from this situation. Just 20 lines of code > to reproduce the bug. And you tell me this is not what you want. So what do > you want? A patch that fixes your problem? > > Sorry for harsh words in your address. But in such situations I question > myself should I really report anything and ask anything in FreeBSD > community. > > Btw, if you are still interested, I think I can provide you with the whole > bhyve image in which you can reproduce the bug. It contains modified > /etc/nsswitch.conf if you cannot change it yourself. Just to follow up, we got a simpler repro based on the one you provided. A few bugs were found and fixed as a result: https://cgit.freebsd.org/src/commit/?id=21f749da82e755aafab127618affeffb86cff9a5 https://cgit.freebsd.org/src/commit/?id=513320c0f1122f096468c0b01623ba7c7e77cbe2 https://cgit.freebsd.org/src/commit/?id=85d028223bc2768651f4d44881644ceb5dc2a664 https://cgit.freebsd.org/src/commit/?id=57f22c828ec01e0d92bc8858f61df06b4d81ea5c > сб, 9 янв. 2021 г., 21:47 Konstantin Belousov : > > > On Sat, Jan 09, 2021 at 08:25:46PM +0300, Vasily Postnicov wrote: > > > Brilliant! It took me almost a day to dive into ZeroMQ to reassure > > > myself that there is nothing wrong with it. When I tried to write > > > minimal test programs which call fork after pthread_create() in all > > > combinations. When I realized that NSS stub module is what I need. > > > > > > Instructions: > > > > > > 1) Compile NSS stub module: cc -shared -fPIC -pthread -o > > > nss_zerodns.so.1 test.c (Note '.1' at the end). > > > 2) Copy nss_zerodns.so.1 to /usr/local/lib > > > 3) Apply the patch src_sbin_ping_main.c to ping source code. With this > > > patch ping will not quit too early when the initial call to > > > getaddrinfo() fails. > > > 4) Add stub module to /etc/nsswitch.conf: edit 'hosts' line to be > > > 'hosts: files dns zerodns' > > > 5) Ping non-existent host, like 'ping foo.bar' > > > 6) Ping will hang. The child process which it creates cannot be killed > > > even with killall -9 ping > > > > This is exactly what I do not want. Provide a standalone binary (or > > binaries) that can be just run and demonstrate the issue. Without > > editing nsswitch.conf or patching ping. > > From owner-freebsd-net@freebsd.org Thu Jan 14 19:34:41 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C6D64EBDCE for ; Thu, 14 Jan 2021 19:34:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DGvdr2Yl9z4qJw for ; Thu, 14 Jan 2021 19:34:40 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 10EJYUk1048934 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Jan 2021 11:34:30 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 10EJYTsV048933; Thu, 14 Jan 2021 11:34:29 -0800 (PST) (envelope-from jmg) Date: Thu, 14 Jan 2021 11:34:29 -0800 From: John-Mark Gurney To: "Andrey V. Elsukov" , Lutz Donnerhacke , freebsd-net@freebsd.org, Hans Petter Selasky Subject: Re: FreeBSD does not reply to IPv6 Neighbor Solicitations Message-ID: <20210114193429.GT31099@funkthat.com> Mail-Followup-To: "Andrey V. Elsukov" , Lutz Donnerhacke , freebsd-net@freebsd.org, Hans Petter Selasky References: <20210105031528.GA91534@admin.sibptus.ru> <00a101d6e33b$96edf0c0$c4c9d240$@donnerhacke.de> <20210105104650.GA7688@admin.sibptus.ru> <00b601d6e35a$115a4a20$340ede60$@donnerhacke.de> <20210112022525.GN31099@funkthat.com> <95be49e2-56cc-cf3f-3515-8f13f14ddbad@yandex.ru> <20210112213707.GP31099@funkthat.com> <065eaff7-35bd-0cd3-f68f-849be2178574@yandex.ru> <20210114015917.GR31099@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210114015917.GR31099@funkthat.com> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 14 Jan 2021 11:34:30 -0800 (PST) X-Rspamd-Queue-Id: 4DGvdr2Yl9z4qJw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yandex.ru,donnerhacke.de,freebsd.org,selasky.org]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; MAILMAN_DEST(0.00)[freebsd-net]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 19:34:41 -0000 John-Mark Gurney wrote this message on Wed, Jan 13, 2021 at 17:59 -0800: > Andrey V. Elsukov wrote this message on Wed, Jan 13, 2021 at 11:42 +0300: > > On 13.01.2021 00:37, John-Mark Gurney wrote: > > >> when this will happen again, it would be nice to make sure that NS > > >> packets hit the IP stack. E.g. with attached dtrace script. > > > > > > Ok, I ran the dtrace script when I reproduced the problem, and it did > > > not produce any output. > > > > > > These are effectively what the script does: > > > 9) configure inet6 addresses on ure and bge (duplicating the addresses > > > already configured) > > > > Does it mean that you just reconfigure address without removing it? It > > looks like the problem, that was discussed here > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233535 > > Yeah, I guess it is the same... > > > > bge0: > > > inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 > > > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 > > > group ff01::1%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:00:00:00:01 > > > group ff02::1%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:00:00:00:01 > > > group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:ff:xx:xx:xx > > > > > > so, I made things works, and ran ifmcstat again, and this time it has > > > an additional group in the output: > > > [...] > > > bge0: > > > inet6 fe80::12e7:c6ff:fexx:xxxx%bge0 scopeid 0x2 > > > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 > > > group ff02::1:ff00:c43c%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:ff:00:c4:3c > > > group ff01::1%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:00:00:00:01 > > > group ff02::1%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:00:00:00:01 > > > group ff02::1:ffxx:xxxx%bge0 scopeid 0x2 mode exclude > > > mcast-macaddr 33:33:ff:xx:xx:xx > > > > > > and the tcpdump output: > > > 21:10:53.938655 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 > > > 21:10:55.001428 IP6 fc00:b5d:41c:7e37::7e37 > ff02::1:ff00:c43c: ICMP6, neighbor solicitation, who has fc00:b5d:41c:7e37::c43c, length 32 > > > > Since ff02::1:ff00:c43c%bge0 is not configured in first case, IP stack > > just ignores NS messages and they don't hit ND6 code. > > > > In the PR 233535 the problem was reproducible with MLDv1, so if you > > disable MLDv2 will it work (to reduce possible scope of problematic code)? > > > > net.inet6.mld.v2enable=0 > > I just tested this, and it does not fix the problem for me. > > Do I need to reboot or something? If I set it to 0, the bug > still appears, and also the ifmcstat has the line: > mldv2 flags=2 rv 2 qi 125 qri 10 uri 3 > > is there something else that needs to be done to disable mldv2? I was able to reproduce using epair on a single system. It did take a few runs of the test before it failed, but it was able to fail. So, to reproduce, on a -current system (mine is main-c255640-gc38e59ce1b0), do: ifconfig epair0 create sh ipv6.failure.sh init epair0a epair0b sh ipv6.failure.sh run epair0a epair0b sh ipv6.failure.sh run epair0a epair0b sh ipv6.failure.sh run epair0a epair0b sh ipv6.failure.sh run epair0a epair0b In my case, it failed on the fourth try, but it does appear to be inconsistent, as a fifth run worked, but then the sixth run failed again, and additional runs worked... If you want to see the live tcpdump, you can run the following commands in a coupld different windows: jexec testjail tcpdump -n -p -i epair0a and: jexec checkjail tcpdump -n -p -i epair0b uname -a: FreeBSD test 13.0-CURRENT FreeBSD 13.0-CURRENT #7 main-c255640-gc38e59ce1b0: Sat Jan 9 01:55:25 UTC 2021 root@test:/usr/obj/usr/src.git/amd64.amd64/sys/GENERIC amd64 and the cpu: CPU: AMD PRO A10-8770E R7, 10 COMPUTE CORES 4C+6G (2794.80-MHz K8-class CPU) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@freebsd.org Fri Jan 15 14:47:01 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8853C4E7EDC for ; Fri, 15 Jan 2021 14:47:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DHPCS31gYz5381 for ; Fri, 15 Jan 2021 14:47:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 10FEkjIp076293 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Jan 2021 14:46:48 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.10] (dadv@dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 10FEkci2049939 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 15 Jan 2021 21:46:38 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: 'dropped due to full socket buffers' by SNMP To: Victor Gamov , freebsd-net@freebsd.org References: <388da9a7-7b89-89b2-54eb-17d0e818c924@otcnet.ru> <4e41c1d2-19bc-0345-0b03-526e4cb785c7@otcnet.ru> <6c780827-e764-8053-356b-a921e0892c15@grosbein.net> <7e51a6be-aea1-51c6-c0bd-10d00c19d5d3@grosbein.net> <888c8e91-c8f2-ad4b-9fcf-64c09432f2d5@otcnet.ru> From: Eugene Grosbein Message-ID: Date: Fri, 15 Jan 2021 21:46:37 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <888c8e91-c8f2-ad4b-9fcf-64c09432f2d5@otcnet.ru> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,LOCAL_FROM, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains * -0.2 NICE_REPLY_A Looks like a legit reply (A) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4DHPCS31gYz5381 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.06 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:4f8:c2c:26d8::2:from]; SPAMHAUS_ZRD(0.00)[2a01:4f8:c2c:26d8::2:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[empty SPF record]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.96)[-0.964]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 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, 15 Jan 2021 14:47:01 -0000 05.01.2021 16:39, Victor Gamov wrote: >>> As I understand hw.ix.flow_control=3 to allow flow-control for negotiation. >>> Real PAUSE setting will be set during negotiation. >> >> At the moment of congestion. > > As I understand PAUSE feature negotiated during auto-negotiation process. If flow-control disabled on one side (switch for example) then other side (host) will not to use this feature too. Is it right? Modulo firmware bugs. >>> So where I can find active flow-control setting for host interface? >> Can't check for ix just now, but for em(4) there is sysctl dev.em.0.fc. >> It should be similar for ix. > I have hw.ix.flow_control=3 (what does is it means ?) and dev.ix.0.fc=3 (and what does is it means?) /* Flow Control Settings */ enum ixgbe_fc_mode { ixgbe_fc_none = 0, ixgbe_fc_rx_pause, ixgbe_fc_tx_pause, ixgbe_fc_full, ixgbe_fc_default }; So, ixgbe_fc_full = 3 (full rx/tx flow control enabled, see sys/dev/ixgbe/ixgbe_type.h). > Back to my original question: is it possible to monitor `netstat -n -p udp -f inet -s` counters by SNMP? There is no standard MIB for these counters but you may always export it with net-mgmt/bsnmp-ucd port and custom OIDs if you use stock bsnmpd (bsnmp-ucd man page has an example). There is similar possibility for net-snmpd.