Re: 12.2 Splay Tree ipfw potential panic source
- Reply: Ryan Stone : "Re: 12.2 Splay Tree ipfw potential panic source"
- In reply to: Lutz Donnerhacke : "Re: 12.2 Splay Tree ipfw potential panic source"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 09 Jul 2021 00:53:01 UTC
On 7/8/2021 18:11, Lutz Donnerhacke wrote:
> On Thu, Jul 08, 2021 at 05:38:35PM -0400, Karl Denninger wrote:
>> This is the only change I'm aware of in the build I just put on a firewall
>> that uses ipfw heavily, and it is not panic'ing quite regularly.
> The code was delayed considerably for MFC until such problems are
> identified, tested and solved (AFAIK) in main. The tests are also present in
> stable, and the CI system (jenkins) did not report any failure after MFCing.
>
>> I'll see if I can get a dump from it but that may be difficult as the
>> machine in question is a "small box" without attached storage (boots from
>> an SD card.)
> That would be really helpful. Most notably the bud I can't find easily are
> in the area of inbound redirection and protocol helpers. My use case is
> Carrier Grade NAT (outbound).
The box in question has a material number of "permanent" hole punch
redirects for inbound links, to wit:
${fwcmd} nat 100 config if ${oif} log same_ports reset
redirect_port tcp ${fwd}:2552 2552 redirect_port tcp
192.168.10.214:8080 8080 redirect_port tcp 192.168.10.203:443 4443
redirect_port tcp 192.168.10.216:8080 8088 redirect_port
tcp ${fwd}:993 993 redirect_port tcp ${fwd}:4552 4552 redirect_port tcp
${fwd}:imaps imaps redirect_port tcp ${fwd}:11443 11443 redirect_port
tcp ${fwd}:80 80 redirect_port tcp ${fwd}:2200 22042
The kernel with the splay-tree improvements survives less than /five
minutes /before it blows up -- repeatedly. There is a client (on an
Android phone) that maintains a connection via one of those
(specifically, to the 10.214 ip) along with inbound email on 2552 from
an off-site relay.
I will see if I can get at least a panic backtrace, although the
impacted box is a pcEngines firewall that boots of an SD card. An AMD
box running the same rev but without any ipfw side of things running has
been up for a couple of days without incident. Odds are reasonably-high
the splay tree changes are responsible since that's the "stand-out"
difference between the two boxes.
--
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/