From nobody Sun Oct 12 08:28:40 2025 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 4ckttf4JGJz6BWS5 for ; Sun, 12 Oct 2025 08:29:14 +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 4ckttf28T5z3PvR for ; Sun, 12 Oct 2025 08:29:14 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Authentication-Results: mx1.freebsd.org; none Received: from hub2.goneo.de (hub2.goneo.de [IPv6:2001:1640:5::8:53]) (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 887D42405D9; Sun, 12 Oct 2025 10:29:12 +0200 (CEST) Received: from hub2.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 hub2.goneo.de (Postfix) with ESMTPS id 51319240349; Sun, 12 Oct 2025 10:29:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walstatt-de.de; s=DKIM001; t=1760257750; 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: in-reply-to:in-reply-to:references:references; bh=yfQQOIlhSfCD/JzrfMCMIMgzK8/BZUtP4GC1EXb4Z58=; b=UMeQ4s8nsXfp/OWF5jprCIti10RGFduQAYMF+FRHa0j5eAyxC/SLZs5uWxXqC8NuT9+UoZ r7BZ1newqbOcQr8KV/Z2t6cj26jCY6zm+fUZDQDQaWhSLmgtzgNOTezZoU+lea8PEvWadS lT/bMUIYTRpok7FqJC7gCr7khz60l0rPh4R8fsJkMVsu5W3/e5u2ulUvunmSdVYVeRXLqG aG7UUeUr8BjqIGN/JC/MPKwLRVHr5kCsvXomLj/7ThNVWhfhMokPDot0OzcXEz2k7uRnl5 BHIbLnujq1eSURafcMMLUANWx/Lx89ZYpKAwTST56Mq0sH6vApFFkJOzmkWgdA== Received: from thor.sb211.local (dynamic-2a02-3100-19ba-c502-934b-d8c4-4501-575f.310.pool.telefonica.de [IPv6:2a02:3100:19ba:c502:934b:d8c4:4501:575f]) (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 hub2.goneo.de (Postfix) with ESMTPSA id D80202400FD; Sun, 12 Oct 2025 10:29:07 +0200 (CEST) Date: Sun, 12 Oct 2025 10:28:40 +0200 From: A FreeBSD User To: David Wolfskill Cc: FreeBSD CURRENT Subject: Re: ipfw: ipfw: Adding record failed: Inappropriate ioctl for device Message-ID: <20251012102907.06e49c52@thor.sb211.local> In-Reply-To: References: <20251011155130.47db5448@thor.sb211.local> X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) 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: multipart/signed; boundary="Sig_/Ins/b=tEIECb/10SRoEuKSw"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Rspamd-UID: 735592 X-Rspamd-UID: d8b24e X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4ckttf28T5z3PvR --Sig_/Ins/b=tEIECb/10SRoEuKSw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tage des Herren Sat, 11 Oct 2025 13:49:23 -0700 David Wolfskill schrieb: > On Sat, Oct 11, 2025 at 03:51:15PM +0200, A FreeBSD User wrote: > > Hello, > >=20 > > running a small home brewn firewall appliance based upon FreeBSD 14-ST= ABLE and IPFW, I > > switched the base to 15-STABLE (FreeBSD 15.0-STABLE #5 n280665-6eb4708a= 84d7: Sat Oct 11 > > 09:08:00 CEST 2025 amd64). > >=20 > > Now I face a serious issue with formerly flawless running skripts filli= ng ipfw tables and > > the readynes of the system after a reboot. > > ... =20 >=20 > I believe that I have a simple reproduction of (the core of) the problem: >=20 > g1-48(15.0-S)[82] pwd > /tmp > g1-48(15.0-S)[83] uname -aUK > FreeBSD g1-48.catwhisker.org 15.0-STABLE FreeBSD 15.0-STABLE #454 > stable/15-n280665-6eb4708a84d7: Sat Oct 11 14:58:22 UTC 2025 > root@g1-48.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY a= md64 1500500 > 1500500 g1-48(15.0-S)[84] ipfw table 1 flush g1-48(15.0-S)[85] ipfw table= 1 list > g1-48(15.0-S)[86] cat t1 table 1 add 1.0.1.0/24 > table 1 add 1.0.2.0/23 > table 1 add 1.0.8.0/21 > table 1 add 1.0.32.0/19 > table 1 add 1.1.0.0/24 > table 1 add 1.1.2.0/23 > table 1 add 1.1.4.0/22 > table 1 add 1.1.9.0/24 > table 1 add 1.1.10.0/23 > table 1 add 1.1.12.0/22 > g1-48(15.0-S)[87] cat t1 | /sbin/ipfw /dev/stdin > added: 1.0.1.0/24 0 > Line 1: Adding record failed: Inappropriate ioctl for device > g1-48(15.0-S)[88] ipfw table 1 list > 1.0.1.0/24 0 > g1-48(15.0-S)[89] ipfw table 1 flush > g1-48(15.0-S)[90] ipfw table 1 list > g1-48(15.0-S)[91] /sbin/ipfw /tmp/t1 > added: 1.0.1.0/24 0 > added: 1.0.2.0/23 0 > added: 1.0.8.0/21 0 > added: 1.0.32.0/19 0 > added: 1.1.0.0/24 0 > added: 1.1.2.0/23 0 > added: 1.1.4.0/22 0 > added: 1.1.9.0/24 0 > added: 1.1.10.0/23 0 > added: 1.1.12.0/22 0 > g1-48(15.0-S)[92] ipfw table 1 list > 1.0.1.0/24 0 > 1.0.2.0/23 0 > 1.0.8.0/21 0 > 1.0.32.0/19 0 > 1.1.0.0/24 0 > 1.1.2.0/23 0 > 1.1.4.0/22 0 > 1.1.9.0/24 0 > 1.1.10.0/23 0 > 1.1.12.0/22 0 > g1-48(15.0-S)[93]=20 >=20 > So it seems that /sbin/ipfw no longer copes with reading from > /dev/stdin, but is OK reading from a regular file. (I had observed the > same behavior in main-n281059-2d9fd2c573c3, now that I know to look for > it.) >=20 > (I note that I had been using a construct involving piping the > "table add" commands to /sbin/ipfw since 2008, shortly after getting the > nudge from Julian to populate a table from a file, rather than invoking > /sbin/ipfw for each table entry.) >=20 > Peace, > david Hello, thanks for the investigation and confirmation. The advantage of reading tables via the approach I used is not to have pinp= oint the table's name in the file and having made this decision in the script filling the ta= ble by reading a file. If the observed behaviour is due to a new well defined behaviour - well, th= en it be so and I have to search for another approach. But my guts tell me there might be som= ething wrong and considered a bug ... Kind regards=20 Oliver=20 --=20 A FreeBSD user --Sig_/Ins/b=tEIECb/10SRoEuKSw Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCaOtm0wAKCRCxzvs8Oqok ry6vAP0R8A7OmabFmZyQfiPj7ZektMPXu+Ad4jCx4bF/BW/2AQEAh5QXjhj3eA20 lnpzsw/H0dD+7JUJ4rbg3qX1jD0r/As= =95aX -----END PGP SIGNATURE----- --Sig_/Ins/b=tEIECb/10SRoEuKSw--