From nobody Tue Mar 29 23:56:47 2022 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 063081A48888 for ; Wed, 30 Mar 2022 00:09:19 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.org (uucp.dinoex.org [IPv6:2a0b:f840::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "uucp.dinoex.sub.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSmy54rNFz4m7C for ; Wed, 30 Mar 2022 00:09:17 +0000 (UTC) (envelope-from pmc@citylink.dinoex.sub.org) Received: from uucp.dinoex.sub.de (uucp.dinoex.org [185.220.148.12]) by uucp.dinoex.org (8.17.1/8.17.1) with ESMTPS id 22U095vT098468 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Mar 2022 02:09:05 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) X-Authentication-Warning: uucp.dinoex.sub.de: Host uucp.dinoex.org [185.220.148.12] claimed to be uucp.dinoex.sub.de Received: (from uucp@localhost) by uucp.dinoex.sub.de (8.17.1/8.17.1/Submit) with UUCP id 22U095md098467; Wed, 30 Mar 2022 02:09:05 +0200 (CEST) (envelope-from pmc@citylink.dinoex.sub.org) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by citylink.dinoex.sub.de (8.16.1/8.16.1) with ESMTP id 22TNxJtw090593; Wed, 30 Mar 2022 01:59:19 +0200 (CEST) (envelope-from peter@gate.intra.daemon.contact) Received: from gate.intra.daemon.contact (gate-e [192.168.98.2]) by gate.intra.daemon.contact (8.16.1/8.16.1) with ESMTPS id 22TNulrJ089453 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Mar 2022 01:56:47 +0200 (CEST) (envelope-from peter@gate.intra.daemon.contact) Received: (from peter@localhost) by gate.intra.daemon.contact (8.16.1/8.16.1/Submit) id 22TNulDa089452; Wed, 30 Mar 2022 01:56:47 +0200 (CEST) (envelope-from peter) Date: Wed, 30 Mar 2022 01:56:47 +0200 From: Peter To: "Bjoern A. Zeeb" Cc: freebsd-stable@freebsd.org Subject: Re: Slow startup from D19488 (rtsol: sendmsg: Permission denied) Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Milter: Spamilter (Reciever: uucp.dinoex.sub.de; Sender-ip: 185.220.148.12; Sender-helo: uucp.dinoex.sub.de;) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (uucp.dinoex.org [185.220.148.12]); Wed, 30 Mar 2022 02:09:08 +0200 (CEST) X-Rspamd-Queue-Id: 4KSmy54rNFz4m7C X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pmc@citylink.dinoex.sub.org designates 2a0b:f840::12 as permitted sender) smtp.mailfrom=pmc@citylink.dinoex.sub.org X-Spamd-Result: default: False [0.14 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[sub.org]; NEURAL_SPAM_MEDIUM(0.94)[0.937]; NEURAL_SPAM_SHORT(0.50)[0.499]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-stable]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:205376, ipnet:2a0b:f840::/32, country:DE]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello Bjoern, thanks much for the quick reply! On Tue, Mar 29, 2022 at 10:04:11PM +0000, Bjoern A. Zeeb wrote: ! On Tue, 29 Mar 2022, Peter wrote: ! ! Hi, ! ! I am a bit puzzled as after two years you are the first one to report ! that problem to my knowledge for either base system or jails. This is what greatly wonders me, too. So I was stronly thinking that I am doing something wrong or unusual. But I cannot figure it out, it just seems that the detrimental effect of the change cannot be avoided (e.g. "service jail start" takes quite long now - there's a lot of them). ! > after upgrading 12.3 to stable/13, I am seeing these ! > errors in all my jails: ! > ! > > Additional TCP/IP options: log_in_vain=1. ! > > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib ! > /usr/local/lib/c cmpat/pkg /usr/local/lib/compat/pkg ! > > 32-bit compatibility ldconfig path: ! > > rtsol: sendmsg on nrail1l: Permission denied ! > > rtsol: sendmsg on nrail1l: Permission denied ! > > rtsol: sendmsg on nrail1l: Permission denied ! > > Starting Network: lo0 nrail1l. ! ! Can you give us a full startup log? It's the above, right from the beginning, and then follows: > lo0: flags=8049 metric 0 mtu 16384 > options=680003 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > groups: lo > nd6 options=21 > nrail1l: flags=8843 metric 0 mtu 1500 > options=28 > ether 06:1d:92:01:01:0a > hwaddr 58:9c:fc:10:28:71 > inet ************* netmask ********** broadcast ************* > inet6 fe80::41d:92ff:fe01:10a%nrail1l prefixlen 64 scopeid 0x2 > inet6 fd00:************ prefixlen 120 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=23 > Starting rtsold. > add host 127.0.0.1: gateway lo0 fib 0: route already in table > add net default: gateway ************* > Additional inet routing options: log ICMP redirect=YES. > add host ::1: gateway lo0 fib 0: route already in table > add net fe80::: gateway ::1 > add net ff02::: gateway ::1 > add net ::ffff:0.0.0.0: gateway ::1 > add net ::0.0.0.0: gateway ::1 > add net default: gateway fd00:************* > Flushed all rules. > Firewall rules loaded. > Firewall logging pseudo-interface (ipfw0) created. > Creating and/or trimming log files. > Updating /var/run/os-release done. > Clearing /tmp (X related). > Updating motd:. > Starting syslogd. > Starting rapp. > Starting cron. > Starting sendmail. > Starting sendmail_msp_queue. > Performing sanity check on sshd configuration. > Starting sshd. > > Wed Mar 30 00:52:15 CEST 2022 ! > Searching the cause I find change 1b5be7204eaeeaf aka D19488 ! > ! > This doesn't work, because the firewall is not yet present. This is ! ! Given you are talking firewall, I assume you are using vnet jails? Yes. ! And given you are talking ipfw I assume your default policy is deny ! and not accept? Yes. ! And given rtsol runs I assume you have IPv6 configured and in use? Yes. Here is how I do it: https://daemon.contact/ankh/articles/X3OyjgTpuv ! The same issue then should also happen in your base system on boot? No. The base system does (second level) prefix delegation and has ipv6_gateway_enable="YES" and rtsold_enable="NO" and is not affected. There is one vnet jail intended as VPN server, which also has these parameters in rc.conf and is also not affected. (I did not yet bother to figure out why, The shell code run from rc.d/netif is a bit lenghty...) ! > happening in rc.d/netif, and that must run before rc.d/ipfw in any ! > case, because the firewall needs to see the netifs. ! ! I thought ipfw could log deal with interfaces coming and going? Maybe it can, but then modifying the rc.d logic so to get "ipfw" run before "netif" - that does likely open a box of worms. Furthermore, I do use ipfw as a genuine rerouting+filtering framework, and that logic is entirely based on the interfaces; all rules belong to exactly two interfaces. Here is a short abstract of the idea: https://forums.freebsd.org/threads/ipfw-or-pf.46706/post-561760 cheerio, PMc