github DanielLavrushin/b4 v1.80.3

3 hours ago

[1.80.3] - 2026-08-30

  • FIXED: A routing table named in /etc/iproute2/rt_tables was not recognised as the one a set was using - ip prints such a table by its name rather than its number, which is how ASUS firmware ships tables 100 and 200, so b4 read its own live policy rule as missing and said so on every pass, the TUN engine left its rules behind on that table when it shut down, and b4 looked for those names in one file while ip also reads the copy that ships with the package.
  • FIXED: A set in proxy or mtproto-ws mode stopped diverting anything on port 443, so Telegram sat at "Connecting" while the same set still worked on its other ports - the per-set prerouting jump moved below the capture engine's own chain in 1.80.0, and NFQUEUE ends the chain, so the reply packets of a diverted connection were taken before the set's socket rule could hand them to its listener; on nftables the two chains carry priorities that settle this, iptables has no priorities and nothing held the order.
  • FIXED: A set routed through an interface built its address list, its marks and its table but never got the rule that sends the mark to that table, so everything it matched left by the ordinary uplink - the rule goes in and the shapes older releases wrote are swept after it, one of those shapes carries no mask, which reaches the kernel as a request to match on the mark value alone, so every kernel up to 4.17, which is what Keenetic, Padavan and the older OpenWrt and Merlin builds run, took the rule that had just gone in, and nothing ever read the policy rules back to notice.
  • FIXED: A domain in a proxy-mode set failed when reached through b4's built-in SOCKS5 server, while the same domain worked for a client passing through - traffic the router originates is marked by the set's own output chain and comes back through prerouting over the local route, where the guard added in 1.80.0 returns any packet that already carries a routing mark, including the set's own.
  • FIXED: A set in proxy mode with a hand-set fwmark took the router's whole network down - the interface path checks such a value and assigns its own where it cannot be carried, the proxy path took it as given, and a value with bits outside the range b4 masks on leaves a policy rule the kernel reads as matching every packet that carries no routing mark at all, so all of it went into the set's local delivery table.

What's Changed

  • changelog: update for version 1.80.3 with proxy-mode fix and various … by @DanielLavrushin in #337

Full Changelog: v1.80.2...v1.80.3

Don't miss a new b4 release

NewReleases is sending notifications on new releases.