Date: Sun, 12 Oct 2025 20:07:33 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: A FreeBSD User <freebsd@walstatt-de.de> Cc: David Wolfskill <david@catwhisker.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: ipfw: ipfw: Adding record failed: Inappropriate ioctl for device Message-ID: <20251012200733.ea68f87a1d22abb857249538@dec.sakura.ne.jp> In-Reply-To: <20251012102907.06e49c52@thor.sb211.local> References: <20251011155130.47db5448@thor.sb211.local> <aOrC07D8zjuU72UP@albert.catwhisker.org> <20251012102907.06e49c52@thor.sb211.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Oct 2025 10:28:40 +0200 A FreeBSD User <freebsd@walstatt-de.de> wrote: > Am Tage des Herren Sat, 11 Oct 2025 13:49:23 -0700 > David Wolfskill <david@catwhisker.org> schrieb: > > > On Sat, Oct 11, 2025 at 03:51:15PM +0200, A FreeBSD User wrote: > > > Hello, > > > > > > running a small home brewn firewall appliance based upon FreeBSD 14-STABLE and IPFW, I > > > switched the base to 15-STABLE (FreeBSD 15.0-STABLE #5 n280665-6eb4708a84d7: Sat Oct 11 > > > 09:08:00 CEST 2025 amd64). > > > > > > Now I face a serious issue with formerly flawless running skripts filling ipfw tables and > > > the readynes of the system after a reboot. > > > ... > > > > I believe that I have a simple reproduction of (the core of) the problem: > > > > 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 amd64 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] > > > > 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.) > > > > (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.) > > > > Peace, > > david > > Hello, > thanks for the investigation and confirmation. > > The advantage of reading tables via the approach I used is not to have pinpoint the table's > name in the file and having made this decision in the script filling the table by reading a > file. > If the observed behaviour is due to a new well defined behaviour - well, then it be so and I > have to search for another approach. But my guts tell me there might be something wrong and > considered a bug ... > > Kind regards > Oliver > > -- > > A FreeBSD user The simplest approach would be to use temporary file, rather than pipe. -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20251012200733.ea68f87a1d22abb857249538>