From nobody Sun Oct 12 11:07:33 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 4ckyPZ4xbqz6BkwS for ; Sun, 12 Oct 2025 11:07:46 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 4ckyPZ0dn2z3fMS for ; Sun, 12 Oct 2025 11:07:45 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; none Received: from kalamity.joker.local (124-18-6-240.area1c.commufa.jp [124.18.6.240]) (authenticated bits=0) by www121.sakura.ne.jp (8.18.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 59CB7XWf099706; Sun, 12 Oct 2025 20:07:34 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dec.sakura.ne.jp; s=s2405; t=1760267254; bh=ppfDX+ksA1ipMmuhkpA6PPtglqA1ldvlZ1p29USUS0A=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=hl/r0XpY8mtBNwsZ4xkPcUBCLtYVNggeyKbRj5G5QJegf9jWDpUB0VHTpQqcyJxD4 bGcG0YsUHFH6faYlwqm4PETwY2U3xiOgeA+AGaE1AcuCAu7UWBrabwJUAwSbxFmu+P hzNKdpNBZKiuwyAnGhmw6TY4KYVEGlGrlEywf4hE= Date: Sun, 12 Oct 2025 20:07:33 +0900 From: Tomoaki AOKI To: A FreeBSD User Cc: David Wolfskill , FreeBSD CURRENT 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> <20251012102907.06e49c52@thor.sb211.local> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4ckyPZ0dn2z3fMS On Sun, 12 Oct 2025 10:28:40 +0200 A FreeBSD User wrote: > 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, > > > > > > 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