Date: Tue, 10 Dec 2024 02:27:10 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: FreeBSD User <freebsd@walstatt-de.de> Cc: Juraj Lutter <otis@FreeBSD.org>, Ronald Klop <ronald@FreeBSD.org>, 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> <f8952585-4b68-4cfd-a60f-1ebbd7f2545f@FreeBSD.org> <8E43EAA1-BA3E-4655-ACE1-2E4523E901DE@FreeBSD.org> <20241209214314.2443b590d774423a2b97f0a8@dec.sakura.ne.jp> <20241209174541.39c286f5@thor.intern.walstatt.dynvpn.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Dec 2024 17:45:14 +0100 FreeBSD User <freebsd@walstatt-de.de> wrote: > Am Mon, 9 Dec 2024 21:43:14 +0900 > Tomoaki AOKI <junchoon@dec.sakura.ne.jp> schrieb: > > > On Mon, 9 Dec 2024 11:09:14 +0100 > > Juraj Lutter <otis@FreeBSD.org> wrote: > > > > > > On 8 Dec 2024, at 20:30, Ronald Klop <ronald@FreeBSD.org> 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 <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20241210022710.88c9087dd7cb09774507f232>