Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

From: FreeBSD User <freebsd_at_walstatt-de.de>
Date: Mon, 09 Dec 2024 18:19:20 UTC
Am Tue, 10 Dec 2024 02:27:10 +0900
Tomoaki AOKI <junchoon@dec.sakura.ne.jp> schrieb:

My apology for topposting.

The host I first realised the problems is updated on an almost daily basis and the issue
reported started last weekend.

A possible candidate could be

https://cgit.freebsd.org/src/commit/sys/netpfil/ipfw?id=0fc7bdc978366abb4351b0b76b50a5848cc5d982

since the other, younger, seem innocent. I try to revert the patch mentioned and see ...

> 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.
> 



-- 
O. Hartmann