Loading HoneyMesh...
Loading HoneyMesh...
Measured proof · 29–31 October 2026
Three separate tests show signed ban sharing in a disposable lab, Node application evidence reaching a local packet rule, and a bounded live canary on the Exchange. Each used a separate control source; the Node tests and live canary also checked release or expiry. The results below describe only those tested paths.
15
Lab host and traffic cases after one manual ban
2
Address families in the live Exchange canary
120s
Natural expiry checked on a live test rule
Isolated AMD64 lab · illustration of the tested path
Operator issues a MANUAL ban. Host A enforces locally and signs a mesh signal for its trusted peers.
Accepts the signal as REMOTE_MESH and enforces its own ban.
Accepts the signal as REMOTE_MESH and enforces its own ban.
Each host used a private virtual Ethernet pair and network namespace. Test and control sources were separate. The arrow shows ban sharing, not packet routing. This manual federation test is separate from the Node app tests below.
Five traffic cases · three hosts
The same test source reached hosts A, B, and C before the operator issued a ban on A. After the signed ban reached B and C, that source received no reply in any tested case. A separate unbanned source still reached all three hosts. 3/3 means all three hosts.
“No reply” means the corrected client probe timed out after 1.5 seconds; this was not a packet-capture count. The detailed report explains the preliminary run and the fresh one-minute ban used for the final result.
One signed manual ban on host A was accepted by B and C and enforced on all three AMD64 hosts across the five tested IPv4 TCP, UDP, and ICMP cases. The unbanned source stayed reachable.
This lab did not measure automatic detection accuracy, false positives, propagation latency, production load, peer outage recovery, IPv6 federation, or Arm64 federation. The manual ban was not generated by the Node app.
Isolated Node integration · 31 October 2026
A separate plain Node service imported the HoneyMesh Node Guard package. Repeated invalid signatures from one designated source produced a signed event over a protected local socket. The agent applied a generic-XDP rule on a disposable test interface. That source lost ICMP replies; the separate control source kept replying. Switching to TEST released the rule and restored the source.
The application identifies a repeated behavior from a verified client source.
The agent checks the signed local event, source scope, mode, and short expiry.
The agent acknowledges a local kernel rule only after its map update succeeds.
TEST mode removes the app rule; a separate short rule also expired naturally.
The exact agent build also passed selective IPv4 and IPv6 drops, unlisted-source exclusion, protected-source rejection, TEST release, and expiry on a disposable interface. This independent Node service has not been connected to the production agent with its own credential.
Live Exchange canary · 31 October 2026
A disposable client supplied one exact IPv4 and one exact IPv6 test source. For each family, 40 unauthenticated machine API requests returned 401. The agent then recorded a kernel-applied rule for that source; subsequent HTTPS requests from it received no HTTP response. A separate control connection continued to receive HTTP 200 over IPv4 and IPv6.
40 → no reply
401 responses came first; later test-source HTTPS probes had no response after the agent rule was applied.
200
Independent controls kept reaching the site over both address families.
Released + expired
TEST mode restored both paths; a second IPv4 rule expired after 120 seconds and restored access.
After the test, the agent was returned to TEST, automatic app packet blocking was disabled, public XDP was detached, zero agent bans remained, and the disposable client was deleted. This is a dated canary result, not a display of current blocks. See the live Exchange activity.
The public canary covered exact-source HTTPS no-reply, not every protocol or a sustained attack. Dedicated XDP drop counters and packet capture were not collected. These runs do not establish line-rate throughput, detection accuracy, false-positive rates, multi-tenant isolation, high availability, or a customer-ready self-service install. The live local app ban was not shared to other networks; direct and Exchange sharing remain separate opt-in workflows.
The nine linked summaries show the before-ban, after-ban, and control outcomes for each lab host. Each summary was checked against its underlying private test record. The public PDFs explain the method, the separate Node and live tests, recovery, and limits.
Verify public download checksumsPublic records use host labels and summarized results. Source addresses, cloud identifiers, full command output, management paths, credentials, and private audit databases stay out of this evidence set. The underlying records are retained privately. The federation lab used the 2.3.6-rc2 AMD64 release candidate; the Node canary used a later private hardened agent build.