Hi guys,

I would like to add TCP functionality to lightway-laser as a project for Google Summer of Code (GSoC), 2022. It would be awesome if expressvpn register as an organisation for GSoC.

Thank You

After compiling and running on latest patched Centos 8 image I attempted to utilize the reference package of lightway-laser for a client/server test but ran into an issue when trying to run the most basic tests as documented: https://github.com/expressvpn/lightway-laser

Expected Behavior

After bringing up the client and server on two different VMs I was expecting a valid IP address and Tun interface on both to go up/active.
Client device = wolfssl-01 Server device = wolfssl-02

Current Behavior

From basic debugging the client appears to be functional from a network standpoint and is receiving an IP address from the server:

Startup:

sudo ./lw.out --client --protocol udp --username test --password test --server_ip '192.168.0.49' --server_port 19655 --cert shared.crt --tun helium-test [18:50:44.725344s] Starting client... [18:50:44.725425s] Connecting to: 192.168.0.49:19655 [18:50:44.725432s] Username: test [18:50:44.725435s] Client cert: shared.crt [18:50:44.725438s] Streaming Mode: false [18:50:44.725442s] Tun device: helium-test

5: helium-test: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1350 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 10.125.0.2 peer 10.125.0.1/32 scope global helium-test valid_lft forever preferred_lft forever inet6 fe80::f61a:8c2d:7a82:e292/64 scope link stable-privacy valid_lft forever preferred_lft forever

The client device is also properly updating the route table:

10.125.0.1 dev helium-test proto kernel scope link src 10.125.0.2

The server shows a different behavior where the server appears to be starting properly:

sudo ./lw.out --server --protocol udp --username test --password test --server_ip '0.0.0.0' --server_port 19655 --cert shared.crt --key server.key --tun helium-test [18:58:51.001022s] Starting server... [18:58:51.001105s] Listening on: 0.0.0.0:19655 [18:58:51.001111s] Username: test [18:58:51.001115s] Server cert: shared.crt [18:58:51.001118s] Server key: server.key [18:58:51.001121s] Streaming Mode: false [18:58:51.001124s] Tun device: helium-test

Looking at the network devices I see the new helium-test however the state is incomplete.

7: helium-test: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 500 link/none

With the interface never going active no route is ever installed in the route table on the server pointing towards the client.

When trying to ping from the client to the server expected IP:

[19:02:16.711474s] Error writing to TUN device[19:02:17.717433s] Error writing to TUN device[19:02:18.741458s] Error writing to TUN device[19:02:19.765450s] Error writing to TUN device[19:02:20.790663s] Error writing to TUN device[19:02:21.813424s] Error writing to TUN device[19:02:22.837489s] Error writing to TUN device[19:02:23.861464s] Error writing to TUN device^C

Each ICMP packet causing a error writing to Tun.

TCPDUMP on the server shows the incoming packet:

[[email protected] ~]# tcpdump host 192.168.0.48 dropped privs to tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes 19:02:40.245486 IP 192.168.0.48.46886 > wolfssl-02.19655: UDP, length 140 19:02:40.245534 IP wolfssl-02 > 192.168.0.48: ICMP wolfssl-02 udp port 19655 unreachable, length 176 19:02:41.269365 IP 192.168.0.48.46886 > wolfssl-02.19655: UDP, length 140 19:02:41.269417 IP wolfssl-02 > 192.168.0.48: ICMP wolfssl-02 udp port 19655 unreachable, length 176 19:02:42.293458 IP 192.168.0.48.46886 > wolfssl-02.19655: UDP, length 140 19:02:42.293513 IP wolfssl-02 > 192.168.0.48: ICMP wolfssl-02 udp port 19655 unreachable, length 176 19:02:43.317359 IP 192.168.0.48.46886 > wolfssl-02.19655: UDP, length 140 19:02:43.317404 IP wolfssl-02 > 192.168.0.48: ICMP wolfssl-02 udp port 19655 unreachable, length 176 19:02:43.591793 ARP, Request who-has 192.168.0.48 tell wolfssl-02, length 28

From the above the Tun looks established from the Client to the Server but the Server doesn't have a valid route to respond back to the client using the Tun which never goes up.

Possible Solution

None found.

Steps to Reproduce (for bugs)

1. Fresh Centos 8 fully patched
2. Fresh pull of wolfssl
3. Fresh pull of lightway-laser
4. gcc, autoconf, automake, libtool, gem, ceedling, git, docker

5291800 Sep 23 16:51 lw.out

Context

Attempting benchmark lightway across several platforms for analysis. Currently can't run do to server functionality issue.

Your Environment

• Version used:

https://github.com/expressvpn/lightway-laser

• Operating System and version:

CentOS Linux release 8.4.2105

I was trying to implement TCP connection and streaming for lightway-laser. I am having the following issue :

lw.out: src/unix/stream.c:1405: uv_write2: Assertion `(stream->type == UV_TCP || stream->type == UV_NAMED_PIPE || stream->type == UV_TTY) && "uv_write (unix) does not yet support other types of streams"' failed.

Current Behavior

Log :

[email protected]:/lw_reference# scripts/run_iperf_client.sh 
Resolved to target 172.18.0.3 server 172.18.0.2
Check that we have connectivity to the lightway server
PING 172.18.0.2 (172.18.0.2) 56(84) bytes of data.
64 bytes from 172.18.0.2: icmp_seq=1 ttl=64 time=0.094 ms

--- 172.18.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.094/0.094/0.094/0.000 ms
[11:54:16.833530s] Starting client...
[11:54:16.833599s] Connecting to:        172.18.0.2:19655
[11:54:16.833604s] Username:             test
[11:54:16.833608s] Client cert:          certs/shared.crt
[11:54:16.833610s] Streaming Mode:       true
[11:54:16.833613s] Tun device:           helium-test
lw.out: src/unix/stream.c:1405: uv_write2: Assertion `(stream->type == UV_TCP || stream->type == UV_NAMED_PIPE || stream->type == UV_TTY) && "uv_write (unix) does not yet support other types of streams"' failed.
scripts/run_iperf_client.sh: line 15:    37 Aborted                 (core dumped) build/release/lw.out --client --protocol tcp --username test --password test --server_ip ${SERVER} --server_port 19655 --cert certs/shared.crt --tun helium-test
Setting route to 172.18.0.3 via 10.125.0.2
Error: Nexthop has invalid gateway.

Warnings on compilation :

Release build 'lw.out'
----------------------
Compiling flow.c...
cc1: warning: third_party/zlog/tidy/zlog.c: not a directory
cc1: warning: third_party/argparse/tidy/argparse.c: not a directory
src/udp/flow.c: In function ‘tcp_write_cb’:
src/udp/flow.c:282:41: warning: passing argument 2 of ‘uv_write’ from incompatible pointer type [-Wincompatible-pointer-types]
   int res = uv_write((uv_write_t *)req, &state->tcp_socket, &req->buf, 1, on_send);
                                         ^~~~~~~~~~~~~~~~~~
In file included from include/lw.h:24,
                 from src/udp/flow.h:23,
                 from src/udp/flow.c:20:
third_party/builds/libuv/include/uv.h:510:37: note: expected ‘uv_stream_t *’ {aka ‘struct uv_stream_s *’} but argument is of type ‘uv_tcp_t *’ {aka ‘struct uv_tcp_s *’}
                        uv_stream_t* handle,
                        ~~~~~~~~~~~~~^~~~~~
src/udp/flow.c:282:75: warning: passing argument 5 of ‘uv_write’ from incompatible pointer type [-Wincompatible-pointer-types]
   int res = uv_write((uv_write_t *)req, &state->tcp_socket, &req->buf, 1, on_send);
                                                                           ^~~~~~~
In file included from include/lw.h:24,
                 from src/udp/flow.h:23,
                 from src/udp/flow.c:20:
third_party/builds/libuv/include/uv.h:513:36: note: expected ‘uv_write_cb’ {aka ‘void (*)(struct uv_write_s *, int)’} but argument is of type ‘void (*)(uv_udp_send_t *, int)’ {aka ‘void (*)(struct uv_udp_send_s *, int)’}
                        uv_write_cb cb);
                        ~~~~~~~~~~~~^~
src/udp/flow.c: In function ‘he_session_reject_tcp’:
src/udp/flow.c:359:41: warning: passing argument 2 of ‘uv_write’ from incompatible pointer type [-Wincompatible-pointer-types]
   int err = uv_write((uv_write_t *)req, &state->tcp_socket, &req->buf, 1, on_send);
                                         ^~~~~~~~~~~~~~~~~~
In file included from include/lw.h:24,
                 from src/udp/flow.h:23,
                 from src/udp/flow.c:20:
third_party/builds/libuv/include/uv.h:510:37: note: expected ‘uv_stream_t *’ {aka ‘struct uv_stream_s *’} but argument is of type ‘uv_tcp_t *’ {aka ‘struct uv_tcp_s *’}
                        uv_stream_t* handle,
                        ~~~~~~~~~~~~~^~~~~~
src/udp/flow.c:359:75: warning: passing argument 5 of ‘uv_write’ from incompatible pointer type [-Wincompatible-pointer-types]
   int err = uv_write((uv_write_t *)req, &state->tcp_socket, &req->buf, 1, on_send);
                                                                           ^~~~~~~
In file included from include/lw.h:24,
                 from src/udp/flow.h:23,
                 from src/udp/flow.c:20:
third_party/builds/libuv/include/uv.h:513:36: note: expected ‘uv_write_cb’ {aka ‘void (*)(struct uv_write_s *, int)’} but argument is of type ‘void (*)(uv_udp_send_t *, int)’ {aka ‘void (*)(struct uv_udp_send_s *, int)’}
                        uv_write_cb cb);
                        ~~~~~~~~~~~~^~
Linking lw.out...

I am attaching the parts I added in files I felt revelant to this issue :

udp/client.c :

void configure_tcp_client(lw_config_t *config, lw_state_t *state) {
  zlogf_time(ZLOG_INFO_LOG_MSG, "Configuring TCP Client...\n");

  int res = uv_udp_init(state->loop, &state->tcp_socket);
  LW_CHECK_WITH_MSG(res == 0, "Unable to initialise TCP socket");

  res = uv_ip4_addr(config->server_ip, config->server_port, &state->send_addr);
  LW_CHECK_WITH_MSG(res == 0, "Invalid IP address or port");

  int udp_buffer_size = 15 * MEGABYTE;
  uv_send_buffer_size((uv_handle_t *)&state->tcp_socket, &udp_buffer_size);
  uv_recv_buffer_size((uv_handle_t *)&state->tcp_socket, &udp_buffer_size);

  state->tcp_socket.data = state;
  he_ssl_ctx_set_outside_write_cb(state->he_ctx, tcp_write_cb);

  return;
}

void start_tcp_client(lw_state_t *state) {
  int res = uv_listen(&state->tcp_socket, DEFAULT_BACKLOG, on_new_connection);
  LW_CHECK_WITH_MSG(res == 0, "Unable to start recv on udp socket");

  return;
}

/udp/flow.c :

/* Callback if a new connection arrives */
void on_new_connection(uv_stream_t *server, int status) {
  if(status < 0){
    zlogf_time(ZLOG_INFO_LOG_MSG, "New connection error %s\n", uv_strerror(status));
    return ;
  }

  /* Create a new client socket */
  uv_tcp_t *client = calloc(1,sizeof(uv_tcp_t));
  int res = uv_tcp_init(server->loop,client);
  LW_CHECK_WITH_MSG(res == 0, "Unable to initialise Client Socket");

/* Accept the client */
  res = uv_accept(server, (uv_stream_t *) client);
  LW_CHECK_WITH_MSG(res == 0, "Unable to accept the client");

/* Read from the client socket */
  res = uv_read_start((uv_stream_t *) client,alloc_buffer,on_read_stream);
  LW_CHECK_WITH_MSG(res == 0, "Unable to read from client socket");

}

he_return_code_t tcp_write_cb(he_conn_t *he_conn, uint8_t *packet, size_t length, void *context) {
  // Get our context back
  lw_state_t *state = (lw_state_t *)context;

  write_req_t *req = (write_req_t *)calloc(1, sizeof(write_req_t));
  LW_CHECK_WITH_MSG(req, "Unable to allocate write request!");

  uint8_t *output_buffer = calloc(1, LW_MAX_WIRE_MTU);
  LW_CHECK_WITH_MSG(output_buffer, "Unable to allocate write buffer");
  memcpy(output_buffer, packet, length);

  req->buf = uv_buf_init((char *)output_buffer, (unsigned int)length);

  int res = uv_write((uv_write_t *)req, &state->tcp_socket, &req->buf, 1, on_send);

  if(res) {
    zlogf_time(ZLOG_INFO_LOG_MSG, "Error occurred during uv_write: %s (%d)\n", uv_strerror(res),
               res);
    return HE_ERR_CALLBACK_FAILED;
  }

  return HE_SUCCESS;
}

Context

I am unable to set up Helium connection when running run_iperf_client.sh

Your Environment

• Version used: lightway-laser latest version
• Operating System and version: Endeavour Os 1.4 - Arch Rolling

It seems to me that Lightway currently does not use multithreading I checked both the official version and the beta version on my Raspberry Pi4 Both versions use only one core use AES, 120mbps is the limit, and ChaCha20 is 170mbps multithreading is needed for fast speed on mobile devices and SBC

AES on Pi4, no big difference in speed with openvpn On the Pi4, Wireguard supports multithreading, resulting in very fast speeds of over 500mbps

But ExpressVPN doesn't support Wireguard, so I wish the lightway was as fast as wireguard !

I'm running iOS 15.1 and the background usage of the app is 29% in the last 24 hours. I'm using the lightway udp protocol and think this might be a bug.

Thank you.

Hello.

How to run with --protocol tcp?

sudo ./lw.out --server --protocol tcp --username test --password test --server_ip '0.0.0.0' --server_port 19655 --cert certs/shared.crt --key certs/server.key --tun helium-test

Exit with Streaming is not supported yet

Description

Explicitly enable 4096 SP, this is automatically enabled on x64 but not on 32bit which causes issues with RSA4096. So explicitly enable it to not rely on implicit behaviours

Motivation and Context

Fixes issues with 32bit builds

How Has This Been Tested?

Manually tested with android on x86 emu

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [ ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] All active GitHub checks are passing
• [ ] The correct base branch is being used, if not main

Description

• Added a new error code: HE_ERR_INVALID_AUTH_TYPE. Client-side code may see this error when the conn->auth_type is set to unsupported value.
• Deprecate he_conn_set_auth_buffer. Client-side code should use he_conn_set_auth_buffer2 instead. And both function will set the auth_type to HE_AUTH_TYPE_CB.
• Server-side code will response "Access Denied" if the auth message contains unsupported auth_type.

Motivation and Context

Previously, a Lightway client can set any value to the auth_type field in the authentication message sent to the server, then the server side code just consider it's using "auth_buffer" without actually checking the value of auth_type. By using a specific code for the "auth buffer based" authentication, we can add support to more auth_type in the future.

How Has This Been Tested?

All changes have been verified with earthly +test to ensure no breaking changes to the API.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] All active GitHub checks are passing
• [x] The correct base branch is being used, if not main

Description

• Use version 5.2.0 of WolfSSL
• Add mock struct for new WolfSSL type (WOLFSSL_X509_EXTENSION)
• Add va_list to treat as array list for test generation

Motivation and Context

Brings WolfSSL up to date.

How Has This Been Tested?

Test suite as part of earthly +all completes successfully

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [X] Upgrade dependency

Checklist:

• [X] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [X] All active GitHub checks are passing
• [X] The correct base branch is being used, if not main

Description

Return a specific error code when the client receives a "goodbye" message from server.

Motivation and Context

The client app may need to perform specific actions when receiving the "goodbye" message from server. Therefore we need a new error code to separate from generic HE_ERR_CONNECTION_WAS_CLOSED errors.

How Has This Been Tested?

This change has been unit tested.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [X] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [X] My code follows the code style of this project.
• [X] My change requires a change to the documentation.
• [X] I have updated the documentation accordingly.
• [x] All active GitHub checks are passing
• [x] The correct base branch is being used, if not main

Fix parameter documentation for conn.h

Description

Some of the parameter documentation is out of date so update it.

How Has This Been Tested?

NIL: documentation update only

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [ ] My code follows the code style of this project.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] All active GitHub checks are passing
• [x] The correct base branch is being used, if not main

Hi there! I am an Iranian developer. If you subscribe to the news, IRAN has blocked all protocols with DPI we can't connect to VPN. We need yours help for setup this protocol with simple script because LightWay protocol not detected by DPI right now and express VPN is working with this protocol.

We can't buy an express VPN for some problems in communicating with national banks and payment getaways. So, we just can setup our VPN servers.

IRAN needs your help

Please make an update and simple script with the last version of lightway-core and replay the link to this message 🙏

I very tried to use from lightway-laser but that is a very old source and I had some issues and errors.

Description

Add additional method for wolfSSL errors

Motivation and Context

This allows us to get detailed SSL errors to ease debugging

How Has This Been Tested?

Has autotests, this was also used to help debug issues internally

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [ ] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [ ] All active GitHub checks are passing
• [ ] The correct base branch is being used, if not main

This comparison with Wireguard (and OpenVPN) could include: security considerations (attack surface, cryptographic primitives used), ease of use, ease of getting started, and OS support (desktop and mobile).

Context

I'm comparing this project to other options and I'd appreciate it if your docs would help with that!