Method for realizing openvpn client on single-chip microcomputer and single-chip microcomputer

Abstract

The invention relates to a method for realizing an openvpn client on a single-chip microcomputer and the single-chip microcomputer, and the method comprises the following steps: simulating a vfs system in linux by using a vfs interface in the single-chip microcomputer, enabling the vfs system to support opening, reading and writing operations of tun equipment, and monitoring a data ready event by using a select mechanism; a Tun virtual network card is added in a netif layer; caching the data by adopting a FreeRTOS message queue; a linux interface and a system calling interface in the openvpn are modified into a FreeRTOS (Real Time Operating System); and integrating an LWIP protocol stack. According to the invention, the application of the openvpn client on the single-chip microcomputer is realized.

Description

Technical Field

[0001] This invention relates to the field of software development, and more particularly to a method for implementing an OpenVPN client on a microcontroller and a microcontroller. Background Technology

[0002] VPN, or Virtual Private Channel, is a tunnel providing secure data transmission between enterprises or between individuals and companies. OpenVPN is a pioneer of open-source VPNs for Linux, offering excellent performance and a user-friendly GUI. Currently, there are no microcontroller-based solutions supporting OpenVPN clients on the market for the following reasons:

[0003] (1) Strong kernel dependency: Traditional OpenVPN implementations rely on the Linux kernel's TUN / TAP driver and kernel protocol stack, and cannot run on microcontrollers without an operating system (such as ESP32).

[0004] (2) High resource consumption: The memory consumption of the Linux kernel protocol stack (usually more than 2MB) far exceeds that of the microcontroller (ESP32 only has 520KB SRAM).

[0005] (3) Insufficient real-time performance: Kernel-mode data transmission requires multiple context switches, resulting in uncontrollable latency and difficulty in meeting the real-time requirements of embedded systems.

[0006] (4) Complex hardware adaptation: The kernel driver needs to be ported to different chips, resulting in a long development cycle and poor compatibility. Summary of the Invention

[0007] To address the aforementioned problems, this invention proposes a method for implementing an OpenVPN client on a microcontroller and a microcontroller itself.

[0008] The specific plan is as follows:

[0009] A method for implementing an OpenVPN client on a microcontroller includes: using the VFS interface in the microcontroller to simulate the VFS system in Linux, enabling it to support open, read, and write operations on the TUN device, while using the select mechanism to listen for data ready events; adding a TUN virtual network card in the NetIF layer; using a FreeRTOS message queue to cache data; modifying the Linux interface and system call interface in OpenVPN to a FreeRTOS; and integrating the LWIP protocol stack.

[0010] The OpenVPN client implemented on a microcontroller executes the following data sending and receiving process:

[0011] In the data receiving process, the OpenVPN client first receives the data and writes it into the data receiving queue. Then, the data is retrieved from the data receiving queue and stored in the Tun virtual network interface card. Next, the data in the Tun virtual network interface card is read and written into the LWIP protocol stack. The LWIP protocol stack then sends the data to the application.

[0012] In the data sending process, the data that the application needs to send is first written into the LWIP protocol stack. Then, the Tun virtual network card reads the data in the LWIP protocol stack and writes it into the data sending queue. When data arrives in the data sending queue, select is woken up to notify the OpenVPN client to start reading data from the data receiving queue.

[0013] Furthermore, when simulating a VFS node device in Linux through the VFS interface, the functions constructed for opening, reading, and writing operations on the TUN device are tun_open, tun_read, and tun_write, respectively. In tun_open, a data receive queue and a data send queue are created to replace the ioctl function in Linux; in tun_read, the xQueueReceive function is called to read data from the data receive queue; and in tun_write, the xQueueSend function is called to write data to the data send queue.

[0014] Furthermore, the operation of waking up select when data arrives in the data receiving queue is implemented through the function tun_select_notify. The function's operation logic is as follows: it monitors a global array that records all active select listening requests in real time. When it detects that data has arrived in the data receiving queue, it wakes up select and notifies the OpenVPN client to start reading data from the data receiving queue.

[0015] Furthermore, the process of retrieving data from the data sending queue and injecting it into the LWIP protocol stack is implemented through a constructed tun_task task. The implementation logic of the tun_task task is as follows: it determines in real time whether there is data in the data sending queue. If there is data, it retrieves the data from the data sending queue and injects the data into the LWIP protocol stack.

[0016] Furthermore, the priority of the tun_task task is set higher than the priority of the OpenVPN client's execution logic.

[0017] Furthermore, it also includes replacing Linux's mutex lock with a portMUX_TYPE spinlock.

[0018] Furthermore, when integrating the LWIP protocol stack, the pbuf_alloc and pbuf_free functions are used to allocate memory space, replacing the malloc function.

[0019] Furthermore, by modifying the OpenVPN encryption / decryption module and calling the AES-NI instruction set, encryption and decryption functions can be implemented on a microcontroller.

[0020] A microcontroller includes an OpenVPN client implemented by the method described in the embodiments of the present invention.

[0021] The present invention adopts the above technical solution to realize the application of OpenVPN client on microcontroller. Attached Figure Description

[0022] Figure 1 The diagram shown is a schematic representation of the corresponding modifications in the method of Embodiment 1 of the present invention.

[0023] Figure 2 The diagram shown is a schematic of the data receiving process in this embodiment.

[0024] Figure 3 The diagram shown is a schematic of the data transmission process in this embodiment. Detailed Implementation

[0025] To further illustrate the various embodiments, the present invention provides accompanying drawings. These drawings are part of the disclosure of the present invention, primarily used to illustrate the embodiments, and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these drawings, those skilled in the art should be able to understand other possible implementations and the advantages of the present invention.

[0026] The present invention will now be further described in conjunction with the accompanying drawings and specific embodiments.

[0027] Example 1:

[0028] This invention provides a method for implementing an OpenVPN client on a microcontroller, such as... Figure 1 As shown, the main modifications include the following: Using the VFS interface in the microcontroller to simulate the VFS system in Linux, enabling it to support open, read, and write operations on the TUN device. Simultaneously, the select mechanism is used to listen for data readiness events. This VFS interface is primarily used for interaction between OpenVPN, TUN, and the LWIP protocol stack. A TUN virtual network interface is added to the NetIF layer for interaction with the application layer. FreeRTOS message queues are used to cache data. The Linux interface and system call interface in OpenVPN are modified to a FreeRTOS interface. The LWIP protocol stack is integrated.

[0029] The OpenVPN client implemented in this embodiment performs the following data sending and receiving process:

[0030] like Figure 2 As shown, the data reception process, which involves data transmission from the OpenVPN server to the OpenVPN client, is as follows: the OpenVPN server sends encrypted data; the microcontroller's physical network interface (such as Wi-Fi) receives the encrypted data and forwards it to the OpenVPN client; the OpenVPN client decrypts the encrypted data and writes it to the data reception queue through the VFS interface; the Tun virtual network card reads the data in the data reception queue in a loop, and when it reads the data, it writes it to the LWIP protocol stack; finally, the LWIP protocol stack sends the data to the application.

[0031] like Figure 3 As shown, the data sending process, which involves data transmission from the OpenVPN client to the OpenVPN server, is a mirror image of the data receiving process described above. Specifically, the application writes the data to be sent into the LWIP protocol stack; the Tun virtual network interface reads the data from the LWIP protocol stack and writes it into the data sending queue; when data arrives in the data sending queue, select is woken up to notify the OpenVPN client to start reading data from the data sending queue; after reading the data, the OpenVPN client encrypts it and sends the encrypted data to the OpenVPN server through the physical network interface.

[0032] In this embodiment, the microcontroller model used is ESP32. The following describes the specific implementation of the above modifications based on this microcontroller model.

[0033] 1. Refactoring of file operation interfaces (VFS layer)

[0034] Linux native interface:

[0035] OpenVPN in Linux uses the / dev / net / tun character device to send and receive network data, relying on the following system calls:

[0036]

[0037] ESP32 Adaptation Modification:

[0038] Virtual device registration:

[0039] Register a custom VFS path (e.g., / dev / tun) using the esp_vfs_register() function, and override the open, read, write, and select functions:

[0040] / / Pseudocode: VFS operation structure

[0041]

[0042]

[0043] Key function logic:

[0044] The `tun_open` function creates two FreeRTOS message queues: a data receive queue (`tun_queue_rx`) and a data send queue (`tun_queue_tx`), replacing the Linux `ioctl` (`TUNSETIFF`) function. `ioctl` is a device control interface function in a device driver. A character device driver typically implements functions such as opening, closing, reading, and writing the device. In more detailed scenarios, if new functionality needs to be added, it is usually achieved by adding `ioctl()` commands.

[0045] The `tun_read` function calls `xQueueReceive(tun_queue_rx, &pbuf)` to retrieve data from the `tun_queue_rx` queue and copies it directly to the application-level buffer. `xQueueReceive` is an important function in FreeRTOS used to receive messages from a queue. Its main function is to read messages from the tail of the queue. If the queue is empty, the task calling this function will be suspended until a message becomes available or a timeout occurs.

[0046] The `tun_write` function writes data from the LWIP protocol stack, encapsulated as a pbuf structure, to the `tun_queue_tx` queue using `xQueueSend(tun_queue_tx)`. `xQueueSend` is an important function in FreeRTOS used to send data to a queue.

[0047] 2. Implementation of the select mechanism

[0048] select, poll, and epoll are three common I / O multiplexing mechanisms. They can all monitor multiple descriptors simultaneously, and once a descriptor is ready (usually ready for reading or writing), they will notify the program to perform the corresponding read or write operation.

[0049] Linux mechanism:

[0050] It relies on the kernel's epoll or poll system calls to listen for data ready events through file descriptors.

[0051] ESP32 Adaptation Modification:

[0052] (1) Dynamic Selector Registry:

[0053] Construct and maintain a global array s_registered_selects to record all active select listening requests (the record includes semaphores and file descriptor sets).

[0054] (2) Event triggering logic:

[0055] In this embodiment, the event triggering logic is executed by constructing the tun_select_notify function. The function's operation logic is as follows: it monitors the above global array in real time, and when it detects that data has arrived in the data receiving queue, it wakes up select and notifies the OpenVPN client to start reading data from the data receiving queue.

[0056] The pseudocode for the tun_select_notify function is as follows:

[0057]

[0058] The pseudocode above uses the `esp_vfs_select_triggered` function to wake up tasks blocked in `select`, simulating Linux's asynchronous notification mechanism. Within the `esp_vfs_select_triggered` function, `select` is woken up based on the semaphore `sem`.

[0059] 3. TUN virtual network adapter driver (netif layer)

[0060] Linux implementation:

[0061] The kernel creates virtual network interfaces using tun_chr_ioctl(), and data is transferred between the kernel protocol stack and the application layer.

[0062] ESP32 Adaptation Modification:

[0063] A TUN network card driver is added to the netif layer of ESP32 by using a custom netif initialization method.

[0064] / / Pseudocode: Registering the TUN network card driver

[0065] struct netif*tun_netif=netif_add(&netif,&ip,&netmask,&gw,NULL,tunif_init,ethernet_input);

[0066] netif_set_up(tun_netif); / / Enable network interface card

[0067] 4. LWIP protocol stack integration optimization

[0068] Key modifications:

[0069] Use the pbuf_alloc and pbuf_free functions to allocate content space instead of the standard malloc function to avoid memory fragmentation.

[0070] 5. Data Flow Control

[0071] OpenVPN client → Protocol stack:

[0072] OpenVPN writes data via write() → tun_write() stores the data in the tun_queue_rx queue → the tun_task task retrieves the data from the tun_queue_rx queue → netif->input(pbuf,netif) is called to inject the data retrieved from the tun_queue_rx queue into the LWIP protocol stack.

[0073] Protocol Stack → OpenVPN Client:

[0074] Store data from the LWIP protocol stack into the tun_queue_tx queue → Trigger select notification →

[0075] OpenVPN reads and encrypts data via `read()`, then reads the data from the `tun_queue_tx` queue using `tun_read()`. In this embodiment, a custom `tun_output` function is used to inject data from the LWIP protocol stack into the `tun_queue_tx` queue.

[0076] `tun_task` is a custom data processing task in this embodiment. Its execution logic is as follows: It checks in real-time whether there is data in the `tun_queue_rx` queue. If there is data, it retrieves the data from the data sending queue and injects it into the LWIP protocol stack. The corresponding pseudocode is as follows:

[0077]

[0078] Furthermore, in order to ensure that data processing in the protocol stack takes precedence over application layer logic, the priority of the tun_task task is set to a high priority in this embodiment, such as configMAX_PRIORITIES (maximum priority) - 2, where configMAX_PRIORITIES is the highest priority in the system.

[0079] 6. Queue operation protection

[0080] To reduce task switching overhead, this embodiment also includes using a portMUX_TYPE spinlock in ESP32 instead of the Linux mutex lock, as shown in the pseudocode below:

[0081] portENTER_CRITICAL(&s_critical_section_lock);

[0082] xQueueSend(queue, &data, timeout); / / Queue operation

[0083] portEXIT_CRITICAL(&s_critical_section_lock);

[0084] 7. Zero-copy data transfer

[0085] ESP32 implementation:

[0086] Receiving path: Data received by the OpenVPN client is directly encapsulated in pbuf format and passed to the LWIP protocol stack through the data sending queue, avoiding memory copying.

[0087] Sending path: pbuf format data from the LWIP protocol stack is transmitted to the OpenVPN client through the data receiving queue, requiring only one memcpy (memcpy is a memory copy function).

[0088] 8. Hardware encryption acceleration

[0089] This paper describes a hardware-based encryption / decryption implementation on the ESP32 microcontroller to improve encryption and decryption speed. Specifically, it involves modifying the OpenVPN encryption / decryption module to call the ESP32's AES-NI instruction set.

[0090] / / Pseudocode: AES-256-CBC encryption

[0091] esp_aes_crypt_cbc(&aes_ctx,ESP_AES_ENCRYPT,len,iv,plaintext,

[0092] ciphertext);

[0093] The embodiments of the present invention have the following beneficial effects:

[0094] (1) User-space virtualization architecture

[0095] Zero kernel dependency: It simulates Linux file operations (open / read / write / select) through the VFS layer, without requiring kernel support.

[0096] Lightweight queue mechanism: Zero-copy data transmission is achieved using FreeRTOS message queues, reducing memory usage.

[0097] (2) Protocol stack optimization

[0098] LWIP Deep Integration: Custom tun_netif network card driver, supports ARP / IPv4 / IPv6 protocols, and reduces protocol stack memory usage.

[0099] Dynamic event notification: Efficient multiplexing is achieved based on semaphores (select_sem) and critical section locks (portMUX_TYPE).

[0100] It adopts a pbuf chain structure to optimize memory allocation and supports dynamic sharding.

[0101] (3) Enhanced security

[0102] Encryption offload optimization: Bind OpenVPN's encryption algorithms (such as AES-256) to the hardware acceleration engine (ESP32 encryption module) to improve throughput.

[0103] Example 2:

[0104] The present invention also provides a microcontroller that includes an OpenVPN client implemented by the method embodiment described in Embodiment 1 of the present invention.

[0105] The preferred microcontroller model is ESP32.

[0106] Although the invention has been specifically shown and described in conjunction with preferred embodiments, those skilled in the art should understand that various changes in form and detail may be made to the invention without departing from the spirit and scope of the invention as defined in the appended claims, all of which shall be within the scope of protection of the invention.

Claims

1. A method for implementing an OpenVPN client on a microcontroller, characterized in that, include: The VFS interface in the microcontroller is used to simulate the VFS system in Linux, enabling it to support opening, reading, and writing operations on the TUN device. The select mechanism is used to listen for data ready events. A TUN virtual network card is added to the netif layer. FreeRTOS message queues are used to cache data. The Linux interface and system call interface in OpenVPN are modified to be a FreeRTOS. The LWIP protocol stack is integrated. The OpenVPN client implemented on a microcontroller executes the following data sending and receiving process: In the data receiving process, the OpenVPN client first receives the data and writes it into the data receiving queue. Then, the data is retrieved from the data receiving queue and stored in the Tun virtual network interface card. Next, the data in the Tun virtual network interface card is read and written into the LWIP protocol stack. The LWIP protocol stack then sends the data to the application. In the data sending process, the data that the application needs to send is first written into the LWIP protocol stack. Then, the Tun virtual network card reads the data in the LWIP protocol stack and writes it into the data sending queue. When data arrives in the data sending queue, select is woken up to notify the OpenVPN client to start reading data from the data receiving queue.

2. The method for implementing an OpenVPN client on a microcontroller according to claim 1, characterized in that: When simulating a VFS node device in Linux through the VFS interface, the functions constructed for opening, reading, and writing operations on the TUN device are: tun_open, tun_read, and tun_write. In tun_open, a data receive queue and a data send queue are created to replace the ioctl function in Linux; in tun_read, the xQueueReceive function is called to read data from the data receive queue; and in tun_write, the xQueueSend function is called to write data to the data send queue.

3. The method for implementing an OpenVPN client on a microcontroller according to claim 1, characterized in that: The operation of waking up select when data arrives in the data receiving queue is implemented through the function tun_select_notify. The function's operation logic is as follows: it monitors a global array that records all active select listening requests in real time. When it detects that data has arrived in the data receiving queue, it wakes up select and notifies the OpenVPN client to start reading data from the data receiving queue.

4. The method for implementing an OpenVPN client on a microcontroller according to claim 1, characterized in that: The process of retrieving data from the data sending queue and injecting it into the LWIP protocol stack is implemented through a constructed tun_task task. The implementation logic of the tun_task task is as follows: it checks in real time whether there is data in the data receiving queue. If there is data, it retrieves the data from the data sending queue and injects the data into the LWIP protocol stack.

5. The method for implementing an OpenVPN client on a microcontroller according to claim 4, characterized in that: Set the priority of the tun_task task to be higher than the priority of the OpenVPN client's execution logic.

6. The method for implementing an OpenVPN client on a microcontroller according to claim 1, characterized in that: It also includes replacing Linux's mutex lock with a portMUX_TYPE spinlock.

7. The method for implementing an OpenVPN client on a microcontroller according to claim 1, characterized in that: When integrating the LWIP protocol stack, the pbuf_alloc and pbuf_free functions are used to allocate memory space instead of the malloc function.

8. The method for implementing an OpenVPN client on a microcontroller according to claim 1, characterized in that: By modifying the OpenVPN encryption / decryption module and calling the AES-NI instruction set, encryption and decryption functions can be implemented on a microcontroller.

9. A microcontroller, characterized in that: The microcontroller includes an OpenVPN client implemented using any one of the methods described in claims 1 to 8.

Images