[1.76.0] - 2026-08-10
- FIXED: Every name lookup took five seconds once a set was routed through a proxy or an interface - each answer for such a set was written into the firewall from the same thread that reads packets from the kernel, one
ipsetprocess per address, so nothing was read for as long as those processes took. Packets arriving meanwhile were dropped by the kernel without a word, and a lookup for a name b4 has no interest in crosses that queue several times, so it was the one most likely to lose a packet and wait out the resolver's five-second retry. - CHANGED: The addresses from a DNS answer are written to the firewall in the background, in one batch - the same addresses were re-added on every answer for the name, at one process per address, which on a router is most of a second of work repeated for traffic that changed nothing.
- FIXED: A DNS request sent by the router itself was handed to b4 twice - the rule that captures it sat in a chain reached from two places, so every such request paid the round trip to b4 and back a second time for no purpose.
- CHANGED: A burst of packets no longer overruns b4 while it is busy - the kernel's hand-off buffer was left at the system default, a few hundred kilobytes shared by every packet in flight.
- FIXED: System diagnostics reported jq and other tools as missing when they were installed on a USB drive - the check never looked outside the router's own folders.
- ADDED: Pinned addresses for a domain - when a CDN keeps answering with an address the firewall drops, no bypass strategy reaches the server at all, and the only remedies were a hosts file on every device or a
dnsmasqalias on the router, both redone by hand each time the CDN changed its addresses. Written in hosts file order, address first. A pin only applies to names the set already targets, which is easy to get wrong silently, so a pin naming something the set does not match says so and offers to add it.Sets > DNS. - FIXED: A curated DNS answer could name the very address b4 was about to reset - when every address in an answer was unreachable, the replacement was taken from the addresses remembered for that name without checking whether any of them had since been marked unreachable as well, so a device could be handed one and have the connection reset on its first packet.
- CHANGED: Every address seen in a DNS answer is remembered, not only the ones that completed a handshake - a name whose answers carry a single address, as the Meta CDN does, left nothing to fall back to once that address was dropped, because an address could only be remembered by connecting to it and the block is what stops the connection.
- FIXED: Telegram messages arrived while photos, videos and stickers did not, in the WebSocket bridge routing mode - a client marks a connection as a media one by the sign of the data center number it sends in its opening handshake, and b4 took that number from the address the client had dialled instead, which carries no such mark. Every media session was therefore announced to Telegram as an ordinary one and answered by the wrong half of the data center. The address now settles which data center it is, the client's handshake whether it is the media one.
- FIXED: Data center 203, the one Telegram serves media from, had no WebSocket route other than a Cloudflare Worker of your own - the shared Cloudflare pool and a custom WebSocket domain were both addressed as
kws203, a name that exists nowhere; Telegram carries that data center underkws2. What remained was a direct connection to it, which is exactly what a censored network drops, so media stopped at the network rather than at any strategy. - FIXED: A TCP connection was listed under a set whose port filter excludes it - a set narrowed to a single TCP port, or to one TLS version, still had its name written next to every TCP connection it matched by address, so a set built to take only UDP looked as though it kept taking TCP after being scoped away from it. The connection itself was already left alone; only the name in the table said otherwise.
- FIXED: The Traffic page said nothing about what happened to a DNS request - which resolver answered it, whether the answer came from a pin, had unreachable addresses replaced, was turned into NXDOMAIN or dropped outright, all of that was written into the connection record and then discarded by the interface, which could only draw the five markers it had been taught. The documentation listed the outcomes as visible on that page while the page showed a bare UDP row.
- ADDED: A documentation page for DNS - what b4 does with name lookups was written down only in pieces, beside each setting it belonged to. DNS.
- FIXED: Every firewall rule was torn down and rebuilt every few seconds on some systems - the chain that catches DNS over TCP from the router itself was created with a priority named after a place it cannot sit, so the whole DNS table was rolled back; the rule monitor then found that table missing and restored all of b4's rules from scratch on its next pass, over and over. Each rebuild leaves a moment in which nothing is intercepted at all.
What's Changed
- fixes 1-75-1 by @DanielLavrushin in #297
Full Changelog: v1.75.0...v1.76.0