github DanielLavrushin/b4 v1.84.0

2 hours ago

[1.84.0] - 2026-09-30

  • ADDED: Expose to internet switches for the ports of the web interface, the MTProto and SOCKS5 proxies and the Telegram Desktop WEB proxy, off by default - each opens its port in the firewall and keeps it open through firewall restarts, and the MTProto share dialog can switch its link to the internet address.
  • ADDED: System Info, the log and the Telegram over WebSocket card name the network bridges that keep the devices behind them out of proxy sets and Telegram over WebSocket - with net.bridge.bridge-nf-call-iptables at 1, which the dockerd package sets on OpenWrt, the kernel loses the handover to b4's listener for connections that enter through a bridge such as br-lan, so they hung without a single log line while the router's own connections worked. The Bridge netfilter row under Firewall in System Info names the setting to turn off.
  • ADDED: Set DSCP writes a DSCP value into the packets the host sends out, off by default - a router in front of b4 can then recognise b4's traffic by a field in the packet, which b4's internal packet marks never carry off the host. The switch is under Settings, Core, Firewall Features, and the value and the interfaces appear in the DSCP group once it is on.
  • FIXED: The settings page asked for a restart of b4 after a change to the SOCKS5 proxy, to the web interface's username, password or language, or to the MCP settings, none of which needs one - it counted every change on the Core tab as needing a restart, and the MCP settings of the Integrations tab as Core ones.
  • FIXED: Discovery, including the watchdog's runs for a set, lost some of its probe packets and ran several times slower on a site that an enabled set already covered - b4's packet queue took Discovery's packets again on their way out of the router: on iptables, and on nftables with some mark settings, such as a Packet Mark changed from the web interface.
  • FIXED: A changed Packet Mark took effect only in part: routing sets kept the old value until the next firewall check or a restart; on iptables the old value's CONNMARK rule stayed even after b4 stopped; and a save from the web interface left Discovery's marks at the old value plus 1 and plus 2 - routing sets were compared without the Packet Mark, a firewall refresh cleared what the new settings would have installed instead of what was installed, and the configuration stored Discovery's derived marks.
  • FIXED: On iptables, b4 deleted masquerade rules it had not added at every start, stop and firewall refresh: a plain -j MASQUERADE in nat POSTROUTING, and -o <interface> -j MASQUERADE for each interface listed under NAT Masquerade - it still removed by their text the rules that versions before 1.71.0 had put there, and identical rules of the router matched.
  • FIXED: One malformed address, such as 10.0.0.0/99 or a name, in a set with packet duplication kept the NFQUEUE packet engine from starting, and in TUN mode, when a set with packet duplication covered many addresses, such as a GeoIP category or an ASN, the web interface came up a minute or more after start, with a routing set the bypass then stopped for about as long again, and stopping b4 in that time timed out and left its capture rules behind - b4 handed the set's addresses to ipset or nft unchecked, and one entry the tool rejects fails the whole load; in TUN mode it gave each duplication address a firewall rule of its own and added them one command at a time, ahead of the rules that capture the first packets of every connection, and on iptables-legacy every command rewrites the whole table, so the capture chain took longer to build with every address, at start and again right after it, once the routing sets were in place.
  • FIXED: In TUN mode on a kernel that lacks some iptables modules: without the raw table or the CT target, such as Synology DSM, connections the device forwarded for others, like Docker containers on a bridge network or LAN clients, failed past the local network while the device's own connections worked; without xt_connbytes, a connection that matched a set got the set's DPI bypass on every packet instead of only its first ones, which slowed traffic through it many times over and wrote a log line per packet - without b4's NOTRACK rule, the copies of the forwarded packets that b4 sent on went through connection tracking a second time, and the kernel's NAT gave them a new source port, so the replies came back to a port nothing listened on; and b4 left it to the kernel's connbytes match to hand over only the first packets of a connection, and without that match the TUN engine received and processed whole connections.
  • FIXED: The first connection to an address a routing set learned from a DNS answer could leave outside the set, directly instead of through a proxy set's upstream or the set's interface - b4 passed the answer on to the device before the addresses in it were in the set, and the device connected in the meantime.
  • FIXED: Connections that a proxy set sent to its upstream were listed without the site name on the Traffic page and in the log while Send domain name to upstream was off, or when the set listed only addresses and b4 had seen no DNS answer for the address - b4 read the name from the connection only when it needed one for the upstream.

What's Changed

Full Changelog: v1.83.1...v1.84.0

Don't miss a new b4 release

NewReleases is sending notifications on new releases.