https://npuforge.org/news/ Releases and measurements of os-xgs-npu: Sophos XGS hardware, back as open firewalls. en https://npuforge.org/news/a-site-of-its-own/ https://npuforge.org/news/a-site-of-its-own/ Tue, 20 Oct 2026 00:00:00 +0000 The project npuforge.org: the documentation, the measurements and the story in one place, searchable, in light and dark, with a home page in English and in Arabic. https://npuforge.org/news/release-0-1-0-alpha-2-2/ https://npuforge.org/news/release-0-1-0-alpha-2-2/ Mon, 19 Oct 2026 00:00:00 +0000 Releases A small update: from this release an appliance sends its problem reports to the project's own domain, `reports.npuforge.org`. The earlier address keeps answering, for the appliances that have not updated yet. https://npuforge.org/news/release-0-1-0-alpha-2-1/ https://npuforge.org/news/release-0-1-0-alpha-2-1/ Mon, 19 Oct 2026 00:00:00 +0000 Releases A small update on the same day: the Updates page, as the three appliances were updated to 0.1.0-alpha.2 from it. An appliance installed from a test branch is offered the release, a reboot is asked for only when the driver changed, and the changes are listed with their links. Every step of an update is photographed in the guide, docs/guide/updating.md. https://npuforge.org/news/release-0-1-0-alpha-2/ https://npuforge.org/news/release-0-1-0-alpha-2/ Mon, 19 Oct 2026 00:00:00 +0000 Releases Two days of work on both appliances, gathered. The XGS 136 forwards connections in its coprocessor through a takeout that works, revives a connection its fast path gives back and holds one that keeps coming back, and reads the coprocessor's own counts into pf and the interfaces. Block lists and TLS fingerprints cut connections already open, and unusual traffic is reported. Every page of the XGS menu renders again on appliances set up by the installer, and each cage reports the medium its module carries. https://npuforge.org/news/measured-xgs3300-many-2026-10-19/ https://npuforge.org/news/measured-xgs3300-many-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements The same run as on the XGS 136 (a thousand connections at once): https://npuforge.org/news/measured-xgs136-soak-2026-10-19/ https://npuforge.org/news/measured-xgs136-soak-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements The XGS 3300's integrity soak (two hours of TLS), made on the XGS 136 for the first time: https://npuforge.org/news/measured-xgs136-giveback-2026-10-19/ https://npuforge.org/news/measured-xgs136-giveback-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements When the second XGS 3300 sent to the bench PC through the XGS 136, a stream in hardware ran slower than the same stream through the host, and retransmitted far more. The fast path kept giving the connection back, and the driver kept making it again at once - and making it again was what gave it back. The driver now waits, with the connection left with the host, before it makes one the fast path gave back soon after it was made. In that direction the hardware path now runs level with the host's, and a minute of it retransmits a quarter of what it did (#529). https://npuforge.org/news/measured-xgs136-counts-2026-10-19/ https://npuforge.org/news/measured-xgs136-counts-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements The XGS 3300's coprocessor sends the host the counts of every connection it forwards, and of every port, as control messages on tag 254 - which the driver now reads and gives to pf and the interfaces (hw-counters-2026-10-19.md). The XGS 136 is as blind to its own hardware traffic as the XGS 3300 was: once a connection is in hardware, pf's state and the interface counters stop growing. This page is the first step of the same work on the XGS 136: does its coprocessor send such messages at all, and in what form. https://npuforge.org/news/measured-xgs136-after-boot-2026-10-19/ https://npuforge.org/news/measured-xgs136-after-boot-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements Four times on 2026-10-19 a stream from the bench PC through the XGS 136 to the second XGS 3300 ran at a quarter to a third of its speed for a short while (#531, open). This page is what was done to find the cause, and what was found on the way. The cause has not been found: in 28 minutes of watching and one boot watched, it did not happen again. https://npuforge.org/news/measured-rpc-bounds-2026-10-19/ https://npuforge.org/news/measured-rpc-bounds-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements Both drivers post some commands to the coprocessor without waiting for the answer: on the high RPC ring, each into a slot of its own. A review found that neither driver kept such a command inside its slot (#524): https://npuforge.org/news/measured-lists-cut-2026-10-19/ https://npuforge.org/news/measured-lists-cut-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements XGS: Settings - Cut open connections when listed. A block list in OPNsense is an alias - a pf table filled from a URL, a feed or by hand - and a rule that blocks it blocks new connections only. A connection opened before its address was listed keeps its pf state, and with offloading on its flow in the coprocessor, for as long as it carries traffic. With a list chosen here, scripts/xgs/lists_cut.py compares it every minute (cron) and when the settings are saved with what it held before, and kills by id every pf state with either end in what was added; each driver then takes the connection out of hardware. Choosing a list cuts what it already names. https://npuforge.org/news/measured-ja4-cut-2026-10-19/ https://npuforge.org/news/measured-ja4-cut-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements XGS: Settings - Cut connections by TLS fingerprint. JA4 is a fingerprint of a TLS ClientHello - the version, ciphers, extensions and protocols a client offers - so it names the software that opened a connection rather than the address it went to. OPNsense's Intrusion Detection (Suricata 8) writes one for every TLS connection it sees once its TLS log carries the JA4 field. With fingerprints listed here, scripts/xgs/ja4_cut.py reads that log every two seconds (started each minute by cron) and when the settings are saved, and kills by id every pf state of a connection it shows with a listed fingerprint; the driver then takes the connection out of hardware, as it does for a block list (lists-cut-2026-10-19.md). https://npuforge.org/news/measured-hw-counters-2026-10-19/ https://npuforge.org/news/measured-hw-counters-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements Once a connection is in hardware the host stops seeing it: its frames go from port to port inside the coprocessor, and pf's state, the interface counters and every graph built on them stop growing - which is why every throughput on these pages is read at the far end, not on the appliance. The coprocessor itself counts every connection it forwards, and the XGS 3300's sends those counts to the host unasked, about once a second, as control messages on tag 254 - which the driver had dropped unread since the receive path was written. Since this change it reads them (octep_dp_cmsg_rx in contrib/octep/octep_dp.c): each connection in the table keeps the packets and bytes the coprocessor counted for each direction, dev.octep.0.dp.flow_table prints them, and the Offloaded Flows page shows them as Counted in hardware. https://npuforge.org/news/measured-dos-probe-2026-10-19/ https://npuforge.org/news/measured-dos-probe-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements No - not on the XGS 3300's firmware (v22). The question came from the vendor's own design: its command list has three commands between the QoS ones and the first IPsec one - DOS_SET_POLICY, DOS_ADD_BLACKLIST_ENTRY and DOS_CLEAR_BLACKLIST, 27, 28 and 29 - with their structures in dos_table.h: a policy (a packets-per-second ceiling, a type, whether a source over the ceiling is blacklisted, and for how long) and an entry (a family, a type, an address, a duration). The XGS 136's helper module was built with two more facts about them - an even type is a source and the next odd one its destination; an entry lasts 30 seconds by default and 3,600 at most - and with an error code for a full DoS table. If the coprocessor kept such a table, a block list could be enforced there, at the port, before a frame reached the host. https://npuforge.org/news/measured-cage-medium-2026-10-19/ https://npuforge.org/news/measured-cage-medium-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements A port in a cage reported a medium that nobody had read (#533): https://npuforge.org/news/measured-anomaly-2026-10-19/ https://npuforge.org/news/measured-anomaly-2026-10-19/ Mon, 19 Oct 2026 00:00:00 +0000 Measurements XGS: Settings - Watch for unusual traffic. Off until it is turned on, and it never blocks: it says, in the XGS log, what no normal day looks like. Every minute scripts/xgs/anomaly.py (cron) reads pf's state table every ten seconds through a window of fifty, keeps every connection any reading saw, and for each host that opened connections works out what it did in the window - bytes sent and received, connections opened, new addresses reached, and the most ports it tried on any one address. Then: https://npuforge.org/news/release-0-1-0-alpha-1-1/ https://npuforge.org/news/release-0-1-0-alpha-1-1/ Sun, 18 Oct 2026 00:00:00 +0000 Releases A small update on the same day as the first release: the problem reporter tells crashes apart correctly, and the chipset's own record of why the host last reset is kept at every boot. The Updates page shows a progress bar while it installs. The repository gains its community files. https://npuforge.org/news/release-0-1-0-alpha-1/ https://npuforge.org/news/release-0-1-0-alpha-1/ Sun, 18 Oct 2026 00:00:00 +0000 Releases The first release: everything merged until this day, as one version an appliance can be updated to and back from. Nothing here is advised for a firewall carrying real traffic - ~~read the notice at the top of the README first~~ read the README's "Getting it onto an appliance" first (the work-in-progress notice was lifted on 2026-10-18). What each appliance has and lacks, side by side: [docs/families/parity.md](docs/families/parity.md). https://npuforge.org/news/measured-xgs136-hardware-2026-10-18/ https://npuforge.org/news/measured-xgs136-hardware-2026-10-18/ Sun, 18 Oct 2026 00:00:00 +0000 Measurements The first measurement of a connection crossing the XGS 136 in its coprocessor's fast path rather than through the host: the same traffic, the same ports, once with the host forwarding it and once with the flow maker on, both ways. Each run was taken in a window of its own and photographed when it finished. https://npuforge.org/news/measured-ipv6-and-queues-2026-10-18/ https://npuforge.org/news/measured-ipv6-and-queues-2026-10-18/ Sun, 18 Oct 2026 00:00:00 +0000 Measurements Two measurements of the same night's driver work, each taken in a window of its own and photographed when it finished: https://npuforge.org/news/measured-mtu-2026-10-17/ https://npuforge.org/news/measured-mtu-2026-10-17/ Sat, 17 Oct 2026 00:00:00 +0000 Measurements Measured 2026-10-17 on the bench: one TCP stream for ten seconds in each direction, in clear text and through the IPsec tunnels (AES-GCM-256, in the engines at both ends), at eight MTUs from the smallest to the largest. Every run's window was photographed when it finished; the 52 pictures are in docs/images/measurements/mtu-2026-10-17/ and below each table. https://npuforge.org/news/measured-bench-2026-10-17/ https://npuforge.org/news/measured-bench-2026-10-17/ Sat, 17 Oct 2026 00:00:00 +0000 Measurements The first measurements with a hardware peer at both ends of every tunnel: until this night the far end of a measured tunnel was a firewall doing ESP in software, so a figure could be that firewall's rather than the appliance's. Every window a number came from was photographed when the run finished, and the pictures are below each table.