From nobody Mon Dec 2 12:55:30 2024 X-Original-To: ipfw@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 4Y23fp3fCcz5fl0w for ; Mon, 02 Dec 2024 12:55:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y23fn6GxBz4yHW for ; Mon, 2 Dec 2024 12:55:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733144129; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vTaJRYVQmix/4amA641rvOB/K6Ypfo8EqB8nSffmtRs=; b=GqhPrPVCDG3YO0qVgFGTy34VVpTJSUHTDxqb/KfMovswIohzAh9ECK/0sZ5IyTkVRskuIa SsQhZHbdNvZ0T94Yl8s684t1X6dzb2sEE4JjVJt1+u0eYq8chnTjQ6t2Nu1VV1OZ4gdKMp JUixWLwRuQcZj2HjScWPjyPqyzltscM8kjKcKKOoM+a8J/3fok+3MLORUxHy74eIcgYtMr I3SYwzdE9ZNmNjekgxxFn+iUwp8FaosW6wKd3WBBt4aQ2Zqvj5lCJf1L+ZViVDMjdAjGwP HPzdjSVlWEbsM+lk5OXHohSExd0hHFIABw6d2jIPiWqV/If03NL60LXg0ie+Cg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733144129; a=rsa-sha256; cv=none; b=MsuX3VMMArKpnIoLvn2iN3tmyuEAhMdsrDG1oSWRt8Qt2L8jsLoL/sx1C2WKzOGJLFtJsP 2FgEu5uz94wZ45rWesEugCfThVhdQeBcvi8AH2QzO0/r3DOk4Pa4BSKFCcuUUpaAD5ndKI mH9oCibnNaZu9pwV2Xrze4vNS6jELAxW1RGH45CDinLVLxaPvxxYxizgOrMAGnN9f1GYcL WLFT/QU8/nYBSLT0F7BwAJe55a9SCBf5nwruA0yHwuP/OYV6phKYscz8iGvksj/Dr/Hk72 hq/Bgey12njMNBHEuQ8u68639xrOZCs3wli83PNSwCEcZv04EJt2ddoJmW4ChA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y23fn5swMzfJ2 for ; Mon, 2 Dec 2024 12:55:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B2CtTug023799 for ; Mon, 2 Dec 2024 12:55:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B2CtT5r023798 for ipfw@FreeBSD.org; Mon, 2 Dec 2024 12:55:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 213154] allow ipfw nat single pass with ipfw netgraph multi pass Date: Mon, 02 Dec 2024 12:55:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: Alexander88207@protonmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords short_desc cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: IPFW Technical Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-ipfw List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ipfw@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213154 Alexander Vereeken changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch | Summary|[patch] allow ipfw nat |allow ipfw nat single pass |single pass with ipfw |with ipfw netgraph multi |netgraph multi pass |pass CC| |Alexander88207@protonmail.c | |om --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Dec 2 12:57:19 2024 X-Original-To: ipfw@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 4Y23hx3k1Jz5flKT for ; Mon, 02 Dec 2024 12:57:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Y23hx00RZz52rM for ; Mon, 2 Dec 2024 12:57:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1733144241; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GVa9cEPLjc9SR0zPkIjKYmWozOtsZG7khgKqeZVONlE=; b=s3V08T/afWyI9LA7NH3cBi07wh6nXXWhrbHOJ/+J8fLhlgZy9dfrcTRnB1ngFgZW5fjIUc +X3Shv4qUEsVMGUj8Nt+taffUJAFgxfZERF8C5MuIjV2W13Z1dW2PZef2ak7cpLdOwBIhH 8CyO2TePUSW0gk9bx4Bdp+qdHUgx8HAlzXzCS8zUOkj1U07ELQDcN3gQ29R7sgTRwmA2mp OyVRFXKRg+3dDeGW0rk7aO5u1syt08jc+92f5NaX1Iz2Iz0Afoho+8/1KkEOICk3+2QsoC DhpZhlbIMNYx8EdzNo2nbASwfe0ymmoKPk5YODz7zWAAMho/DI+zXE4EO/40Qw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1733144241; a=rsa-sha256; cv=none; b=HqmKVLOOt6M4vLIQgZWLZ7zFTGYOVRHUAHv+ZClwYGAMzxBPrAADFwti1YkA8r4MSGZF9R bkrGWQK3PfEo8+2qk2zCeeoXkmOuZhCC87n8PSDimX3QOldUYV8RrGAjYWW3RM+VrRFBMe EKYnLsWkIBrzyydJpuPFQrjVsiPLEju+/xj5y9RlgMu6SGfJ/gfqopYEOoivGkmDpYh4fC D+S0/SzvnDeNVeUGNVgK7iNk1beHLKPruHR7FzOkDdequ7JKOegCvZNCSyWJC0Lmv1KAmB vHbJknUwYZZhwyWyRQ6Js9N6vkzkkE347dN2xwF78pwcgod9leLuIIlFbzgU5g== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Y23hw6Fjzzf2V for ; Mon, 2 Dec 2024 12:57:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 4B2CvKZi025689 for ; Mon, 2 Dec 2024 12:57:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 4B2CvKLw025688 for ipfw@FreeBSD.org; Mon, 2 Dec 2024 12:57:20 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 167822] [ipfw] start script doesn't load firewall_type if set in rc.conf.d/ipfw Date: Mon, 02 Dec 2024 12:57:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 8.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: Alexander88207@protonmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords cc short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: IPFW Technical Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-ipfw List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ipfw@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D167822 Alexander Vereeken changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|patch | CC| |Alexander88207@protonmail.c | |om Summary|[ipfw] [patch] start script |[ipfw] start script doesn't |doesn't load firewall_type |load firewall_type if set |if set in rc.conf.d/ipfw |in rc.conf.d/ipfw --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Fri Dec 6 02:46:42 2024 X-Original-To: freebsd-ipfw@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 4Y4FzB2zqvz5g7jl; Fri, 06 Dec 2024 02:47:18 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (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 4Y4Fz82G6bz46Wx; Fri, 6 Dec 2024 02:47:16 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=walstatt-de.de header.s=DKIM001 header.b=mgJS8hCF; spf=pass (mx1.freebsd.org: domain of freebsd@walstatt-de.de designates 2001:1640:5::8:30 as permitted sender) smtp.mailfrom=freebsd@walstatt-de.de; dmarc=none Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 7C7C7240E6F; Fri, 6 Dec 2024 03:47:12 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 9F0822402D6; Fri, 6 Dec 2024 03:47:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1733453230; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XdFGH3CMbtptjDEBjebyi+V9iZ7X3JTk/OqwmFdpgmU=; b=mgJS8hCFJs1ZRlboyR+Q++xSfQLhEpvyRnRoSANQv5OWwz/TvNkOO054tFMj8t9BevhgIa WeIN37r3sw/yFZ7TYvMwie+0NGrXVViMNVFSaty/5M230CjUREQg3uUHAecOqs/3NnxlEW exa5ZVkazLJShybzuTnxiYhgE/QbOctY1US+ZvS7j1/ISKFQ6YH73XQwiq3gBW4vQZlfoe JcJxx+nVT5c9jZZziwMxb4wrrNRqn0I/4+7qDSwRayAcqIdsSwKuGQ8EnlMDLXTfW77Srh PcHFPr9KTiJTlu7Ne39chbzjmgG99KyuH5bFRVBAPyR8G59e14VKqkt6HqM6zw== Received: from thor.intern.walstatt.dynvpn.de (dynamic-078-054-013-094.78.54.pool.telefonica.de [78.54.13.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 56A6024029B; Fri, 6 Dec 2024 03:47:10 +0100 (CET) Date: Fri, 6 Dec 2024 03:46:42 +0100 From: FreeBSD User To: freebsd-current@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-ID: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20241205173354.23c4e592@hermann.intern.walstatt.dynvpn.de> References: <20241203204609.68e04364@hermann.dmz.walstatt.dynvpn.de> <6626e5c0-ba01-4966-a28c-82a25251ca3f@app.fastmail.com> <20241205115103.1ed6d7f6@hermann.intern.walstatt.dynvpn.de> <20241205173354.23c4e592@hermann.intern.walstatt.dynvpn.de> Organization: walstatt-de.de List-Id: IPFW Technical Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-ipfw List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ipfw@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: a8d101 X-Rspamd-UID: 61e20b X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_SPF_ALLOW(-0.20)[+ip6:2001:1640:5::8:0/112]; R_DKIM_ALLOW(-0.20)[walstatt-de.de:s=DKIM001]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-ipfw@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[walstatt-de.de]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; SUBJECT_HAS_EXCLAIM(0.00)[]; DKIM_TRACE(0.00)[walstatt-de.de:+] X-Rspamd-Queue-Id: 4Y4Fz82G6bz46Wx X-Spamd-Bar: --- Am Thu, 5 Dec 2024 17:33:54 +0100 FreeBSD User schrieb: I found the culprit! Disabling IPFW ("ipfw disable firewall") turns system back to normal! For the record: on recent CURRENT, since approx. Nov. 30 and/or December 1st CURRENT seems to corrupt network connections. IPFW is compiled statically into the kernel. The problem sketched below can be reproduced in a more or less obvious manner on recent CURRENT: git pull/git clone of a regular FreeBSD source repo or ports via git+https takes either a couple of time (up to several mintes to initiate the pull) - or, in some worse cases here, the box runs into error: RPC failed; curl 56 Recv failure: Operation timed out claws-mail complains about "corrupted/broken stream", fetching emails takes Aeons - forever, the client does not come back even after several hours. > On Thu, 5 Dec 2024 16:55:00 +0100 > Daniel Tameling wrote: > > > On Thu, Dec 05, 2024 at 11:51:03AM +0100, FreeBSD User wrote: > > > On Wed, 04 Dec 2024 17:20:39 +0000 > > > "Dave Cottlehuber" wrote: > > > > > > Thank you very much for responding! > > > > > > > On Tue, 3 Dec 2024, at 19:46, FreeBSD User wrote: > > > > > On most recent CURRENT (on some boxes of ours, not all) fetch/git seem > > > > > to be stuck > > > > > forever fetching tarballs from ports, fetching Emails via claws-mail > > > > > (TLS), opening > > > > > websites via librewolf and firefox or pulling repositories via git. > > > > > > > > > > CURRENT: FreeBSD 15.0-CURRENT #1 main-n273978-b5a8abe9502e: Mon Dec 2 > > > > > 23:11:07 CET 2024 > > > > > amd64 > > > > > > > > > > When performing "git pull" und /usr/ports, I received after roughly 5-7 minutes: > > > > > > > > > > error: RPC failed: curl 56 recv failure: Operation timed out > > > > > > > > Generally it would be worth seeing if the HTTP(S) layers are doing the right thing > > > > or not, and then working down from there, to tcpdump / wireshark and then if > > > > necessary into kernel itself. > > > > > > My skills are limited, according to packet analysis utilizing tcpdum/wireshark (and > > > theory,of course). I tried due to "a feeling" my used older Intel based NIC could have > > > some checksum issues like in the past (I saw e1000 driver updates recently flowing > > > into FreeBSD CURRENT). > > > > > > > > If fetch fails reliably in ports distfile fetching, then isolate a suitable tarball, > > > > and try it again in curl, with tcpdump already prepared to capture traffic to the > > > > remote host. > > > > > > > > tcpdump -w /tmp/curl.pcap -i ... host ... > > > > > > > > env SSLKEYLOGFILE=/tmp/ssl.keys curl -vsSLo /dev/null --trace > > > > /tmp/curl.log https://what.ev/er > > > > > > > > I would guess that between the two something useful should pop up. > > > > > > > > I like opening the pcap in wireshark, it often has angry red and black highlighted > > > > lines already giving me a hint. > > > > > > > > The SSLKEYLOGFILE can be imported into wireshark, and allows decrypting the TLS > > > > traffic as well in case there are issues further in. Very handy, > > > > see https://everything.curl.dev/usingcurl/tls/sslkeylogfile.html for how to do that. > > > > > > > > If your issues only occur with git pull, its also curl inside and supports similar > > > > debugging. Ferreting > > > > through https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems/56094711#56094711 should get you similar info. > > > > > > > > A+ > > > > Dave > > > > > > > > > > Thanks for the hints and precious tips! I'll digg deeper into the matter. > > > > > > In the meanwhile, I updated some other machines running CURRENT since approx. two > > > weeks with an older CURRENT to the most recent one - and face similar but not > > > identical problems! > > > Updating exiting FreeBSD repositories, like src.git and ports.git, show no problems > > > except they take longer to accomplish than expected. > > > Cloning a repo is impossible, after 10 or 15 minutes I receive a timeout. > > > > > > On aCURRENT recently updated and worked flawlessly before (CURRENT now: FreeBSD > > > 15.0-CURRENT #5 main-n274014-b2bde8a6d39: Wed Dec 4 22:22:22 CET 2024 amd64), cloning > > > attempts for 14.2-RELENG ends up in this mess: > > > > > > # git clone --branch releng/14.2 https://git.freebsd.org/src.git 14.2-RELENG/src/ > > > Cloning into '14.2-RELENG/src'... > > > error: RPC failed; curl 56 Recv failure: Operation timed out > > > fatal: expected 'packfile' > > > > > > This is nasty. The host now in question has an i350 based dual-port NIC - the host's > > > kernel is very similar to the box I reported the issue first time, both do have > > > customized kernels (in most cases, I compile several modules like ZFS and > > > several NETGRAPH modules statically into the kernel - a habit inherited from a small > > > FBSD project I configured (I wouldn't say developed) which does not allow loadable > > > kernel modules due to regulations. > > > > > > I hoped others would stumble over this tripwire in recent CURRENT sources, since the > > > phenomena and its distribution over a bunch of CURRENT boxes with different OS states > > > seemingly show different behviour. > > > > > > And for the record: I also build my ports via poudriere and mostly via make. I also > > > rebuilt in a two day's marathon all packages via "make -f" - for librewolf, curl and > > > so on to ensure having latest sources/packages. > > > > > > (I repeat myself here again, sorry, its for the record). > > > > > > Will report in on further development and "investigations" > > > > > > Kind regards and thanks, > > > > > > oh > > > > > > > > > > This is a shot into the dark but is this a virtual machine? VirtualBox 7.1.0 had some > > networking issues that got fixed later. > > No, pure Hardware and FreeBSD ... > > > > > Otherwise I would start with ping and traceroute to figure out if they show this issue > > and where it occurs. > > > > -- O. Hartmann From nobody Fri Dec 6 20:09:20 2024 X-Original-To: freebsd-ipfw@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 4Y4j691dMQz5fp8J; Fri, 06 Dec 2024 20:09:53 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp052.goneo.de (smtp052.goneo.de [85.220.129.60]) (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 4Y4j685hScz564g; Fri, 6 Dec 2024 20:09:52 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub1.goneo.de (hub1.goneo.de [85.220.129.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 5D544240D18; Fri, 6 Dec 2024 21:09:50 +0100 (CET) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 74DE2240562; Fri, 6 Dec 2024 21:09:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1733515788; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9tlVOqP5LtBTwqnsT9G2I7CBMXXcRs9yIPWa6+WZImA=; b=lczPX0ODEy7JGetelVShwKORM1oNWwtcFbgfBKY/66Jf5pwnIzRP//E8EJSF43nfyXomtm hdE7DFTVFf6T2GtwJeLgiEZx3DEVooNOGpbcBdItGMgJBgjQZNL0izTtT/gOTVlTPDQcIO R7juuYScoOkIwleOLHS45QGLFHAanTuIHhmszh4hbsl/lFWsAUjOOmZxKJiFxkeDdTl/zQ 6XP+CayFVTRhOq2qTiI5ZfBePhSZV7psBs/DK1i4wWTayQG4ODbf5xBkXlQa201/7FH9y5 cCknCbX4soTwswiSC6AHez/Tk7XhXxGtTy7Z4cniCCuKN139sFp58TyBcNHB5Q== Received: from thor.intern.walstatt.dynvpn.de (dynamic-089-012-099-016.89.12.pool.telefonica.de [89.12.99.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 2EC8C240560; Fri, 6 Dec 2024 21:09:48 +0100 (CET) Date: Fri, 6 Dec 2024 21:09:20 +0100 From: FreeBSD User To: Ronald Klop Cc: freebsd-ipfw@freebsd.org, freebsd-current@freebsd.org Subject: Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out Message-ID: <20241206210947.3ae835e4@thor.intern.walstatt.dynvpn.de> In-Reply-To: <279848701.11738.1733510402875@localhost> References: <20241206034709.4dd32cc5@thor.intern.walstatt.dynvpn.de> <279848701.11738.1733510402875@localhost> Organization: walstatt-de.de List-Id: IPFW Technical Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-ipfw List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ipfw@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: 51ce02 X-Rspamd-UID: 21f4eb 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:25394, ipnet:85.220.128.0/17, country:DE] X-Rspamd-Queue-Id: 4Y4j685hScz564g X-Spamd-Bar: ---- Am Fri, 6 Dec 2024 19:40:02 +0100 (CET) Ronald Klop schrieb: > Might be useful to share your ipfw config. Sorry, my posting must have been disturbing (having in mind a "deny any rule and then disabling the FW ...). Well, the IPFW setup itself is explained quickly - I use almost the vanilla rc.conf-issued IPFW (settings: firewall_type="workstation", firewall_logif="YES", firewall_myservices="22/tcp", firewall_allowservices="any"). The hosts in question have the following kernel configuration, I provide the option tags that might be of interest or, if not, just for the record, as they are not part of GENERIC, see below. Also, I'll provide some sysctl setting performed via /etc/sysctl.conf.local, see below. The configuration and settings have been mostly unchanged over a couple of months for now and did not induce trouble so far. As it deemed fit regarding time and my limited skills, I disabled and enabled piece by piece of the MAC_ and NETGRAPH_ options - without any success so far - my "measurement" is fetching emails via claws-mail (all TLS). claws-mail reports "corrupted/broken stream", does have authetication issues and is de facto unusable - it doesn't refresh IMAP based email fetches and doesn't even quit without a hard kill. Another "indicator" is the time taken to "git pull" of ZFS filesystems: cloning and pulling takes unusual long (/usr/src is UFS/FFS, /usr/ports on a ZFS pool and since the problem occured, it makes a mutual difference). While git pull or clone mutually stuck and claws-mail is endlessly fetching/authenticating emails and never responding back in a usable manner, performing "ipfw disable firewall" makes all of a sudden the system work again as usual and expected. As reported - the problem spreads across all of my CURRENT hosts as I'm going to update them towards a recent CURRENT (they all share similar static kernel configs as described here). Most of the boxes do not show the weird reluctant behaviour when pulling via git, but weren't capable of cloning, bailing out with the timeout reported earlier. I use one CURRENT box as my personal desktop, so no other (server) CURRENT show the Email problem in detail as described. And, for the record: I haven't commented out the "options IPFIREWALL" yet in the kernel config ... Kind regards oh [ KERNEL config different from vanilla GENERIC ] options RATELIMIT options ZFS options TCPHPTS options MROUTING options IPSEC options SCTP options MAC_BSDEXTENDED options MAC_PORTACL options MAC_IPACL options MAC_NTPD #options MAC_DO options NETGRAPH options NETGRAPH_IPFW options NETGRAPH_ETHER options NETGRAPH_EIFACE options NETGRAPH_VLAN #options NETGRAPH_NAT options NETGRAPH_DEVICE #options NETGRAPH_PPPOE options NETGRAPH_SOCKET options NETGRAPH_KSOCKET options NETGRAPH_NETFLOW #options NETGRAPH_CAR # IPFW firewall options IPFIREWALL options IPFIREWALL_VERBOSE options DUMMYNET # traffic shaper options BPF_JITTER # adds support for BPF just-in-time compiler. # Pseudo devices not in GENERIC. device enc # IPsec device device stf # 6to4 IPv6 over IPv4 encapsulation device carp # Common address redundancy protocol device lagg # Link aggregation device gre # GRE Tunnel device epair # A pair of virtual back-to-back connected Ethernet interfaces device if_bridge # bridge device device vxlan # Virtual eXtensible LAN interface For the MAC_ Modules: the appropriate OIDs (sysctl) are disabled as far as the MAC module influence the initial behaviour if unconfigured, for instance (/etc/sysctl.conf.local) [ /etc/sysctl.conf.local ] security.mac.bsdextended.enabled=0 security.mac.mls.enabled=0 security.mac.portacl.enabled=0 security.mac.do.enabled=0 security.mac.ipacl.ipv6=0 security.mac.ipacl.ipv4=0 # net.bpf.optimize_writers=1 # net.inet.ip.fw.verbose=1 #net.inet.ip.fw.verbose_limit=10 net.inet.ip.fw.dyn_keep_states=1 > > Van: FreeBSD User > Datum: 6 december 2024 03:47 > Aan: freebsd-current@freebsd.org, freebsd-ipfw@freebsd.org > Onderwerp: Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: > Operation timed out > > > > > > > Am Thu, 5 Dec 2024 17:33:54 +0100 > > FreeBSD User schrieb: > > > > I found the culprit! > > > > Disabling IPFW ("ipfw disable firewall") turns system back to normal! > > > > For the record: on recent CURRENT, since approx. Nov. 30 and/or December 1st CURRENT seems > > to corrupt network connections. > > > > IPFW is compiled statically into the kernel. > > > > The problem sketched below can be reproduced in a more or less obvious manner on recent > > CURRENT: git pull/git clone of a regular FreeBSD source repo or ports via git+https takes > > either a couple of time (up to several mintes to initiate the pull) - or, in some worse > > cases here, the box runs into > > error: RPC failed; curl 56 Recv failure: Operation timed out > > > > claws-mail complains about "corrupted/broken stream", fetching emails takes Aeons - > > forever, the client does not come back even after several hours. > > > > > On Thu, 5 Dec 2024 16:55:00 +0100 > > > Daniel Tameling wrote: > > > > > > > On Thu, Dec 05, 2024 at 11:51:03AM +0100, FreeBSD User wrote: > > > > > On Wed, 04 Dec 2024 17:20:39 +0000 > > > > > "Dave Cottlehuber" wrote: > > > > > > > > > > Thank you very much for responding! > > > > > > > > > > > On Tue, 3 Dec 2024, at 19:46, FreeBSD User wrote: > > > > > > > On most recent CURRENT (on some boxes of ours, not all) fetch/git seem > > > > > > > to be stuck > > > > > > > forever fetching tarballs from ports, fetching Emails via claws-mail > > > > > > > (TLS), opening > > > > > > > websites via librewolf and firefox or pulling repositories via git. > > > > > > > > > > > > > > CURRENT: FreeBSD 15.0-CURRENT #1 main-n273978-b5a8abe9502e: Mon Dec 2 > > > > > > > 23:11:07 CET 2024 > > > > > > > amd64 > > > > > > > > > > > > > > When performing "git pull" und /usr/ports, I received after roughly 5-7 minutes: > > > > > > > > > > > > > > error: RPC failed: curl 56 recv failure: Operation timed out > > > > > > > > > > > > Generally it would be worth seeing if the HTTP(S) layers are doing the right thing > > > > > > or not, and then working down from there, to tcpdump / wireshark and then if > > > > > > necessary into kernel itself. > > > > > > > > > > My skills are limited, according to packet analysis utilizing tcpdum/wireshark (and > > > > > theory,of course). I tried due to "a feeling" my used older Intel based NIC could > > > > > have some checksum issues like in the past (I saw e1000 driver updates recently > > > > > flowing into FreeBSD CURRENT). > > > > > > > > > > > > If fetch fails reliably in ports distfile fetching, then isolate a suitable > > > > > > tarball, and try it again in curl, with tcpdump already prepared to capture > > > > > > traffic to the remote host. > > > > > > > > > > > > tcpdump -w /tmp/curl.pcap -i ... host ... > > > > > > > > > > > > env SSLKEYLOGFILE=/tmp/ssl.keys curl -vsSLo /dev/null --trace > > > > > > /tmp/curl.log https://what.ev/er > > > > > > > > > > > > I would guess that between the two something useful should pop up. > > > > > > > > > > > > I like opening the pcap in wireshark, it often has angry red and black highlighted > > > > > > lines already giving me a hint. > > > > > > > > > > > > The SSLKEYLOGFILE can be imported into wireshark, and allows decrypting the TLS > > > > > > traffic as well in case there are issues further in. Very handy, > > > > > > see https://everything.curl.dev/usingcurl/tls/sslkeylogfile.html for how to do that. > > > > > > > > > > > > If your issues only occur with git pull, its also curl inside and supports similar > > > > > > debugging. Ferreting > > > > > > through https://stackoverflow.com/questions/6178401/how-can-i-debug-git-git-shell-related-problems/56094711#56094711 should get you similar info. > > > > > > > > > > > > A+ > > > > > > Dave > > > > > > > > > > > > > > > > Thanks for the hints and precious tips! I'll digg deeper into the matter. > > > > > > > > > > In the meanwhile, I updated some other machines running CURRENT since approx. two > > > > > weeks with an older CURRENT to the most recent one - and face similar but not > > > > > identical problems! > > > > > Updating exiting FreeBSD repositories, like src.git and ports.git, show no problems > > > > > except they take longer to accomplish than expected. > > > > > Cloning a repo is impossible, after 10 or 15 minutes I receive a timeout. > > > > > > > > > > On aCURRENT recently updated and worked flawlessly before (CURRENT now: FreeBSD > > > > > 15.0-CURRENT #5 main-n274014-b2bde8a6d39: Wed Dec 4 22:22:22 CET 2024 amd64), > > > > > cloning attempts for 14.2-RELENG ends up in this mess: > > > > > > > > > > # git clone --branch releng/14.2 https://git.freebsd.org/src.git 14.2-RELENG/src/ > > > > > Cloning into '14.2-RELENG/src'... > > > > > error: RPC failed; curl 56 Recv failure: Operation timed out > > > > > fatal: expected 'packfile' > > > > > > > > > > This is nasty. The host now in question has an i350 based dual-port NIC - the host's > > > > > kernel is very similar to the box I reported the issue first time, both do have > > > > > customized kernels (in most cases, I compile several modules like ZFS and > > > > > several NETGRAPH modules statically into the kernel - a habit inherited from a small > > > > > FBSD project I configured (I wouldn't say developed) which does not allow loadable > > > > > kernel modules due to regulations. > > > > > > > > > > I hoped others would stumble over this tripwire in recent CURRENT sources, since the > > > > > phenomena and its distribution over a bunch of CURRENT boxes with different OS states > > > > > seemingly show different behviour. > > > > > > > > > > And for the record: I also build my ports via poudriere and mostly via make. I also > > > > > rebuilt in a two day's marathon all packages via "make -f" - for librewolf, curl and > > > > > so on to ensure having latest sources/packages. > > > > > > > > > > (I repeat myself here again, sorry, its for the record). > > > > > > > > > > Will report in on further development and "investigations" > > > > > > > > > > Kind regards and thanks, > > > > > > > > > > oh > > > > > > > > > > > > > > > > > > This is a shot into the dark but is this a virtual machine? VirtualBox 7.1.0 had some > > > > networking issues that got fixed later. > > > > > > No, pure Hardware and FreeBSD ... > > > > > > > > > > > Otherwise I would start with ping and traceroute to figure out if they show this issue > > > > and where it occurs. > > > > > > > > > > > > > > > > > > -- > > O. Hartmann > > > > > > > > > > -- O. Hartmann