Blog

The Wireleap client includes support for TUN in both GNU/Linux and macOS, allowing for a “VPN like” experience of tunneling all traffic (both TCP and UDP) on the system through a multiplexed circuit.

However, at the very least, traffic destined for the first relay in the circuit needs to be excluded from the TUN device routing configuration, otherwise this would result in a blackhole. So, what is needed is for the controller to communicate a list of addresses for exclusion to the TUN daemon, as well as a way to update the list if and when the circuit is changed.

Wireleap v0.6.0 is a major update to the client, with a brand new controller including a REST API, splitting out the SOCKSv5 forwarder, and other internal changes and improvements. As such, there are a number of changes users should be aware of.

Please note, this is a backwards incompatible release.

The Wireleap relay software now supports tracking the amount of traffic it relays, both globally and per contract. Using this data, it is also now possible to limit the amount of the traffic it will relay during a configured period, also, both globally and per contract.

This is particularly useful for two reasons. To not exceed any hosting bandwidth quota limits (which may incur unexpected charges), and to allow the allocation of specific amounts of bandwidth per Wireleap network they support.

Libre is the free Wireleap relay network, powered by the community and supporters of the Wireleap project. It is free to use, provided for the purposes of casual usage, testing, and community feedback.

It’s been possible to run the Wireleap client on the WSL (Windows Subsystem for Linux), although there are occasional issues which are very hard to reproduce and therefore fix. Additionally, having WSL as a requirement isn’t optimal, and limits future planned features.

The latest client release (0.5.2) now includes a native build for Windows, so no need for WSL. This release includes support for the SOCKSv5 interface (TUN is not yet supported), ported exec scripts for Windows, as well as a powershell convenience installation script.

The Wireleap client on MacOS reaches feature parity (except for intercept) of the Linux client with TUN device support, allowing for a “VPN like” experience of tunneling all traffic (both TCP and UDP) on the system through a multiplexed circuit.

Additionally, shell completion on Zsh (MacOS and Linux) is now supported in addition to bash completion.

Wireleap now uses built-in h/2 mechanisms instead of the previous implementation which encoded the initial payload (ie. next-hop and sharetoken) and the status messages on error or connection close in the request body.

This results in simplifying the code, simplifying the protocol, faster establishment and closing of connections, and improved performance. Traffic literally passes bytewise from client to target and back with no modification.

Please note, this is a backwards incompatible release.

As mentioned in the Monolithic wireleap repository split, released under MIT post, consumer-provider semantic versioning was in the works. Initial support has now been implemented and released in the latest component versions, along with other improvements.

Please note, this is a backwards incompatible release.

Bash completion is a last minute addition to the upcoming 0.4.0 release, adding shell-completion to all wireleap commands, sub-commands, option flags, as well as exec and config circuit.whitelist.

The wireleap monolithic git repository containing the Wireleap software suite has been split, mainly into component repositories with a few more repositories based on maintainability, interoperability, separation of concerns and the DRY principle.

Splitting a monolithic repository, especially for a decentralized and distributed system composed of multiple components needing to interoperate with each other poses several additional challenges above the usual. Hence, there is a valid reason why projects such as kubernetes use a mono-repository.

None the less, after weighing the pros and cons, we’ve decided to make the split mainly due to the following rationale:

The following image is a side-by-side comparison of two browsing sessions captured with Wireshark. One is browsing to fr01.test.wireleap.com, while the other is using the wireleap client (configured with 2 hops, the first hop being fr01.test.wireleap.com) to browse elsewhere.

Can you tell which is which?

Due to protocol versioning, it is highly recommended to keep clients up to date. This release simplifies the process, bringing inline client upgrade functionality, including an upgrade supervisor, migration and rollback support. The required version is specified by the contract operator-owned directory.

The software suite has been renamed to Wireleap. All the code, documentation and infrastructure has been updated to reflect this change, along with some other changes as detailed below.

Please note, this is a backwards incompatible change, so some action may be required:

Go 1.16 now supports including static files and file trees natively as part of the final executable using the new //go:embed directive. This has resulted in a 47.2% file size decrease of the client binary (from 36M to 19M).

In addition, Setuid and related calls on Linux are now implemented (previously they returned an syscall.EOPNOTSUPP error), which allows the client tun binary to be configured with appropriate privileges for improved security and user-experience, especially in regards to the upcoming GUI frontend.

When using a precompiled binary, it is highly recommended to ensure the file has not been corrupted in transit or tampered with. For this, our build pipeline generates a hashfile to be used to cryptographically verify its integrity via GPG signature and the corresponding binary via checksum hash.

The process can be a little involved when performed manually, so we’ve scripted the process and made it available for the client via get.wireleap.com.

Due to protocol versioning, it is highly recommended to keep relays up to date. This release simplifies the process, bringing automatic relay upgrade functionality, including an upgrade supervisor, migration support and update channels.

This update brings multiplexing as well as experimental TUN device support for the client (on Linux) which forwards all traffic (UDP and TCP) over the circuit.

Please note, this is a backwards incompatible release.

This sequence diagram shows the high-level flow and behind the scenes interaction between Wireleap components, from the perspective of the client.

This sequence diagram shows the high-level flow and behind the scenes interaction between Wireleap components, from the perspective of the relay.

The following image was generated by using a combination of the localtestnet, rakyll/hey, asoorm/hey-hdr, an httpecho server utilizing valyala/fasthttp, hdrhistogram plotfiles, and some custom glue code.

Both the contract and auth now implement double-entry plain-text-accounting (PTA) to track the movement of value each knows about.

Accounting is tracking the flow of valuable commodities, such as money. It clarifies activity and obligations. Double-entry bookkeeping is a process for keeping accounting records reliably. For every movement of value (a transaction), both the source and destination are recorded. Simple arithmetic invariants help prevent errors.

Abstract. A value transfer protocol would allow nodes in a distributed system to be compensated by customers for the service they provide. A payment mechanism provides part of the solution, but the main benefits are lost if the customer is required to pay each node separately and directly, and if the payment is valid without the node actually providing service.

We propose a solution to payments and compensation validity by employing an out-of-band payment intermediary between customers and service providers, defining the service parameters, and facilitating in disbursing funds provided by a customer to service providers proportionally for service provided, based on proof of service. Proof of service, defined in part by share tokens, are cryptographically and independently generated by a customer and included within traffic sent through service providers, serving a dual-role of allowing a way for service providers to authorize service, as well as a representation of value if proven valid for service provided. Service providers accumulate these share tokens to later submit for validation and compensation. By employing a proportional share-based model, compensation is split between service providers according to the number of valid share tokens they accumulate in proportion to the total number of valid shares tokens submitted by all service providers for a specific service plan.

Abstract. A truly net-neutral Internet would not censor, shape or manipulate traffic selectively. A versatile large-scale routing layer that enforces net-neutrality would make this feasible, enabling global unrestricted Internet access, especially for those in repressive regimes who need it the most. An onion-encrypted routing network provides part of the solution, but the main benefits are lost if access to the network is easily censored, and when participation disincentives prevent adoption.

We propose a solution to censored network access using encapsulated traffic indistinguishable from ordinary traffic, while employing several anti-censorship strategies resting on collateral freedom. Additionally, defining appropriate roles that compartmentalize potential abuse and legal liability issues improves the likelihood of network participation. Finally, to achieve widespread adoption, scalability, and long term sustainability of the routing layer, we propose a free and open competitive marketplace that encourages strong network effects, provides consumer freedoms, and sensible economic incentives in the form of compensation to participants for services provided.