Adds a manual IPv6 tunnel switch, names the Windows setting behind the IPv6 failures, and puts Delete in every list box.
Added
- New setting: Disable IPv6 in the tunnel (Settings, under Strict route). OnionHop already retries without IPv6 on its own when the tunnel adapter is refused an IPv6 address, so this is for anyone who hits that on every connect and would rather skip the failed attempt entirely. Requested by a reporter on #81 who had the equivalent switch in v2.
- The log now names the Windows setting behind these IPv6 failures (#81). A reporter traced their failure to a
DisabledComponentsoverride under the IPv6 service key. A stock Windows install does not define that value at all, and once something writes it, Windows can leave IPv6 half-broken even when it is set to0, the value that nominally means "fully enabled". That is why no IPv6 availability check could ever catch this: every API reports IPv6 as working, right up to the point where the adapter is assigned an address. Deleting the value and rebooting fixed it for them. OnionHop only reads it and tells you, and will not change a machine-wide network setting on your behalf. - Delete in the right-click menu of every list box. The menu with Cut, Copy, Paste, Delete and Select all, in your own language, now covers the multi-line boxes in Settings as well as the scanner: the custom bridge list, the bypass and block routing rules, the country lists and the site-category lists. Clearing a pasted bridge list is now Select all followed by Delete, without reaching for the keyboard (tester request).
Fixed
- The IPv6 tunnel fallback added in 3.7.10 now also covers a tunnel that fails at startup (#81). It previously only recovered when the tunnel died after the connection was already up, so machines where the core refuses to start at all, failing with
set ipv6 address: Element not foundinside the first second, still saw the connect fail outright. The tunnel config is now retried once with the IPv6 address stripped, whichever core wrote it. - Hybrid (split tunnelling) mode no longer blocks UDP for apps you kept direct. "Block UDP traffic" exists because Tor cannot carry UDP, so UDP from a Tor-routed app would silently escape the tunnel, but it was applied to everything rather than only those apps. An app you deliberately left direct never touches Tor, so blocking its UDP protected nothing and broke QUIC (HTTP/3): routing a torrent client through Tor while keeping the browser direct left the browser unable to load YouTube. The block is now scoped to the apps actually routed through Tor. Full-tunnel mode is unchanged, and with "Route all web traffic through Tor" on, QUIC is still blocked so browsers cannot use HTTP/3 to route around it.
Downloads
| Platform | File |
|---|---|
| Windows installer | OnionHop-Setup-v3.exe |
| Windows portable | OnionHopV3-Portable-3.7.11-win-x64.zip |
| Windows CLI | OnionHop-CLI-Setup-3.7.11.exe / OnionHopCLI-Portable-3.7.11-win-x64.zip |
| Linux | OnionHop-x86_64.AppImage |
| Linux CLI | OnionHopCLI-3.7.11-linux-x64.tar.gz |
| macOS (Apple Silicon) | OnionHop-3.7.11-macOS-arm64.dmg |
| macOS (Intel) | OnionHop-3.7.11-macOS-x64.dmg |
| macOS CLI (Apple Silicon) | OnionHopCLI-3.7.11-macos-arm64.tar.gz |
| macOS CLI (Intel) | OnionHopCLI-3.7.11-macos-x64.tar.gz |