From nobody Mon Dec 09 17:27:10 2024 X-Original-To: freebsd-current@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 4Y6TMB529wz5gYTS for ; Mon, 09 Dec 2024 17:27:18 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y6TMB0Tnmz4lBw; Mon, 9 Dec 2024 17:27:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-43-234.area1a.commufa.jp [124.18.43.234]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 4B9HRAKp094276; Tue, 10 Dec 2024 02:27:11 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1733765232; bh=en2x43Fk32aVg15ZU2rEscl5LmMO1xFkDr9MQSHLqfs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=oirJ+u08GVJIFZgQ/w1DowLayd93c+mJLzm9XwICdWWMWnkPen5/SZzYjQuey+q1H Y815UbVpADSODsXRd5Yy7A9CdFUyIj41196dJ5GRrKNuzMwaWb9UCYb0INDth8RUoF INbZWLvT7udDXmVToxpMX2dz4EWMdzBT7HEINn5g= Date: Tue, 10 Dec 2024 02:27:10 +0900 From: Tomoaki AOKI To: FreeBSD User Cc: Juraj Lutter , Ronald Klop , freebsd-current@freebsd.org Subject: Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-Id: <20241210022710.88c9087dd7cb09774507f232@dec.sakura.ne.jp> In-Reply-To: <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.1) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP] X-Rspamd-Queue-Id: 4Y6TMB0Tnmz4lBw X-Spamd-Bar: ---- On Mon, 9 Dec 2024 17:45:14 +0100 FreeBSD User wrote: > Am Mon, 9 Dec 2024 21:43:14 +0900 > Tomoaki AOKI schrieb: > > > On Mon, 9 Dec 2024 11:09:14 +0100 > > Juraj Lutter wrote: > > > > > > On 8 Dec 2024, at 20:30, Ronald Klop wrote: > > > > > > > > Hi, > > > > > > > > I can reproduce your error. > > > > > > > > A cronjob which does a scp to another server didn't work anymore. When I go back to the > > > > previous BE it works fine again. Ipfw disable firewall also makes the scp work. > > > > > > > > Scp also seems to work fine if I replace the statefull firewall rules with stateless > > > > "pass all from any to any". > > > > > > Have you tried to allow ICMP in both directions explicitly, in case of stateful rules? > > > > > > — > > > Juraj Lutter > > > otis@FreeBSD.org > > > > I think would usually work for clients with some limited services > > exposed to outside. IIUC, it basically allow all sessions from inside > > and allows limited serivices configured with variables > > via /etc/rc.conf[.local]. > > > > Some notes. > > *Last actual changes in /usr/src/libexec/rc/rc.firewall was at > > Jul.23, 2020. > > https://github.com/freebsd/freebsd-src/commits/main/libexec/rc/rc.firewall > > [cgit.freebsd.org seems to be unstable now.] > > > > *Variable firewall_logif currently does not exist. > > > > *Don't you need allowing 22/UDP, too, like below? > > firewall_myservices="22/tcp 22/udp" > > > > And if you're creating kernel config from scratch (such as copying from > > GENERIC at some point and editing it), it's no longer adviced. > > It's not robust for changes in GENERIC. > > > > Instead, include GENERIC and describe changes you want. > > > > An example (one of my test kernel config for a bit old stable). > > > > ===== Start example ===== > > > > include GENERIC > > > > ident TEST15 > > > > nooptions DDB > > nooptions GDB > > nooptions INVARIANTS > > nooptions INVARIANT_SUPPORT > > nooptions WITNESS > > nooptions WITNESS_SKIPSPIN > > nooptions DEADLKRES > > > > options CAM_IOSCHED_DYNAMIC > > > > device sg > > > > ===== End example ===== > > > > > > Thank you very much for the advice - but I do this kind of confugration now since, I guess, > 2020 or 2021. consider the host's kernel name to be "THOR", then /etc/src.conf has lines > > KERNCONF= THOR > KERNCONFDIR= /etc/config/amd64/kernel_conf/ > > and the target's config file "/etc/config/amd64/kernel_conf/THOR" contains > > include GENERIC > include NODEVICE-THOR > include "std.nodebug" > include ADDON-THOR > > This concept isn't bullet proof, since I had trouble with the relatively recent introduced > "std.nodebug". As you mentioned, NODEVICE contains ALL "nooptions" and "nodevice" and ADDON > contains some extra options not contained in GENERIC. GENERIC is a symbolic link to the > original GENERIC in the appropriate sys folder. > > Thanks to FReeBSD's sophisticated kernel configuration, this hierarchical scheme prevents most > accidents triggered by significant GENERIC changes. > > Do you suspect a misconfiguration due to uncaught changes in GENERIC? > > -- > O. Hartmann Just a possibility. Not sure when it was and which firewall (ipfw? pf? or else?) it was, but IIRC, I've seen some excessive configs to enable non-default options/devices built into kernel caused unwanted changes in default before when I was searching unrelated things of FreeBSD. And why I've mentioned about kernel configuration file is because I've bitten by the changes in GENERIC before. In contrast with rc.firewall, kernel side of ipfw received some changes this year. https://cgit.freebsd.org/src/log/sys/netpfil/ipfw So anything committed after your previous build could cause the issue. Sorry, I have not enough time to dig into deeper. Other points to worth checking would be: https://cgit.freebsd.org/src/log/sys/netgraph https://cgit.freebsd.org/src/tree/sys/net The latter should be limited with bpf related (otherwise too bload). net and netinet would be too bload, too. Bloader codes should be checked when narrow and close codes are analysed to be NOT affecting. Otherwise, there would be too much confusions. -- Tomoaki AOKI