Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out
- Reply: Tomoaki AOKI : "Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out"
- In reply to: Tomoaki AOKI : "Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 09 Dec 2024 16:45:14 UTC
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