Skip to content

update bitmaskcore, integrating obfsvpn

cyberta requested to merge integrate_obfsvpn into master

relates to #9091 (closed)

  • There has been UI added to enable experimental transports - for now only obfsvpn-1 as defined in our dev-documentation. It shows up if Bitmask/RiseupVPN is built with obfsvpn instead of snowflake (for now both libs are still supported, but shapeshifter will be removed as soon as obfsvpn is a little bit more tested in real world conditions) and if the provider has any gateway running with the transport obfsvpn-1.

  • There's no particular UI to select an experimental transport, if the experimental transports option has been enabled, the experimental transports will be added to the pool of possible bridges and selected according to the existing ordering schemes for a 'best location' or a manual location selection. On the provider side the order of transports in eip-service.json for a given gateway matters: the first pluggable transport of a gateway (defined in eip-service.json) will be tried first. Experimental transports should be added in front in order to ensure they will be tried not only after a connection failure. We may want to randomize the selection order of pluggable transports within a single gateway in the future.

  • Additionally for debugging purposes there has been a pinning mechanism added to pin a particular bridge on compile time.

  • The mutual exclusion of the UDP settings UI has been kept, as it refers right now to the openvpn mode, not the protocol on the wire. However obfsvpn supports UDP on the wire. The udp configuration is tied to the selected pluggable transport (obfs4 = tcp, obfs4-1 = udp)

@kali @kwadronaut @mcnair fyi

Edited by cyberta

Merge request reports