pf: avoid passing through dummynet multiple times
In some setups we end up with multiple states created for a single
packet, which in turn can mean we run the packet through dummynet
multiple times. That's not expected or intended. Mark each packet when
it goes through dummynet, and do not pass packet through dummynet if
they're marked as having already passed through.
See also: https://redmine.pfsense.org/issues/14854
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44365
pf: fix reply-to after rdr and dummynet
If we redirect a packet to localhost and it gets dummynet'd it may be
re-injected later (e.g. when delayed) which means it will be passed
through ip_input() again. ip_input() will then reject the packet because
it's directed to the loopback address, but did not arrive on a loopback
interface.
Fix this by having pf set the rcvif to V_iflo if we redirect to
loopback.
See also: https://redmine.pfsense.org/issues/15363
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: fix dummynet + route-to
Ensure that we pick the correct dummynet pipe (i.e. forward vs. reverse
direction) when applying route-to.
We mark the processing as outbound so that dummynet will re-inject in
the correct phase of processing after it's done with the packet, but
that will cause us to pick the wrong pipe number. Reverse them so that
the incorrect decision ends up picking the correct pipe.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D44366
pf: fix dummynet + route-to for IPv6
Apply the fixes from c6f1116357904 and b8ef285f6cc6a to IPv6 as well.
Ensure that when dummynet re-injects it does so in the correct direction, and
uses the correct dummynet pipes.
Sponsored by: Rubicon Communications, LLC ("Netgate")
pf: ensure dummynet gets the correct direction after route-to
If we apply a route-to to an inbound packet pf_route() may hand that
packet over to dummynet. Dummynet may then delay the packet, and later
re-inject it. This re-injection (in dummynet_send()) needs to know
if the packet was inbound or outbound, to call the correct path for
continued processing.
That's done based on the pf_pdesc we pass along (through
pf_dummynet_route() and pf_pdesc_to_dnflow()). In the case of pf_route()
on inbound packets that may be wrong, because we're called in the input
path, and didn't update pf_pdesc->dir.
This can manifest in issues with fragmented packets. For example, a
fragmented packet will be re-fragmented in pf_route(), and if dummynet
makes different decisions for some of the fragments (that is, it delays
some and allows others to pass through directly) this will break.
The packets that pass through dummynet without delay will be transmitted
[15 lines not shown]
Revert "pf: avoid passing through dummynet multiple times"
This reverts commit d8322a6ac465ffe2ef432a4b4d608afdd03150da.
There's no evidence this does anything so leave out changing
pf-dummynet code in this release iteration.
Feature/threat lookup magnifier button (#5044)
* Update Makefile
* Update pkg-descr
* Update security/q-feeds-connector/pkg-descr
Co-authored-by: Franco Fichtner <franco at lastsummer.de>
* Update security/q-feeds-connector/Makefile
Co-authored-by: Franco Fichtner <franco at lastsummer.de>
* Add threat lookup magnifier buttons to events table
- Add magnifier buttons next to source and destination IP addresses in events table
- Buttons open Threat Intelligence Portal in new tab with IP pre-filled
- Automatically triggers search when TIP page loads
[17 lines not shown]
py-channels: updated to 4.3.2
4.3.2 (2025-11-20)
* Confirmed support for Django 6.0.
* Confirmed support for Python 3.14.
* Added ``types`` extra for ``types-channels`` stubs. See installation docs.
[ORC] Add unit test for simple cycle in WaitingOnGraph::emit. (#169281)
WaitingOnGraphTests.Emit_SingleContainerSimpleCycle tests a pair of emit
operations where the second completes a simple cycle (1: A -> B, 2: B ->
A).
We already had a test of WaitingOnGraph::simplify's behavior in this
case, but did not have one for WaitingOnGraph::emit.
The hp300 reserves the last page of RAM to use for the MMU trampoline.
Since this page would otherwise be wasted, put it to good use as the
NULL segment table using a new NULL_SEGTAB_PA hook.
