A WiFi and cellular non-inductive dual-channel parallel communication method

Abstract

This invention provides a method for seamless dual-channel parallel communication using WiFi and cellular networks, comprising the following steps: generating a WiFi hotspot and configuring deceptive DHCP parameters on an IoT device; injecting an empty default route into the IoT device's kernel network stack; configuring allow and discard rules based on the kernel network stack; after a smart terminal connects to the IoT device via the WiFi hotspot, the IoT device executes a probe message response policy based on an Internet access probe request; this causes the smart terminal to automatically migrate the default route from the WiFi network interface to the cellular network interface, while retaining the local subnet route of the WiFi network interface. This invention can construct a dual-channel system that combines WiFi and cellular networks, enabling low-latency, high-bandwidth local data interaction tasks through the WiFi network channel while maintaining real-time connectivity with Internet cloud services through the cellular network channel, without requiring the installation of any app or root access for system settings.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method for parallel communication using both WiFi and cellular non-sensory dual channels. Background Technology

[0002] With the rapid development of IoT technology and the widespread adoption of smart mobile terminals, an increasing number of IoT devices are using WiFi hotspots to connect locally and interact with smartphones and other smart terminals. For example, in industrial inspection, infrared temperature measurement equipment transmits thermal imaging data to a mobile phone in real time via WiFi hotspots; in drone missions, pilots connect to the drone's WiFi via their mobile phones to obtain real-time image transmission data.

[0003] However, existing smart terminal operating systems, when connecting to a WiFi hotspot, by default route all network traffic to the WiFi interface and automatically cut off the external network access capability of the cellular network.

[0004] For example, such as Figure 1 As shown, when the IoT device 200 (such as an infrared thermal imager) does not have internet access capabilities, after the smart terminal 100 and the IoT device 200 connect via a WiFi hotspot, data can be transmitted between the smart terminal 100 and the IoT device 200 (as shown in the image transmission data). At the same time, the smart terminal 100 completely loses its internet access capability, which prevents users from accessing cloud services, map navigation, AI assistants, and other functions that rely on the external network while obtaining local data, thus creating a technical dilemma where "local image transmission and external network services cannot be obtained simultaneously".

[0005] To solve the above problems, existing technologies mostly adopt the following technical solutions:

[0006] 1. Install a dedicated app or modify system settings on the smart terminal to detect the internet connectivity of the WiFi hotspot. When WiFi is unavailable, automatically switch to cellular data, or achieve dual-channel concurrency through VPN or other technologies. However, this solution requires users to install third-party applications or obtain root access to the smart terminal's system. Furthermore, due to Apple's strict restrictions on network switching, this solution is difficult to implement on iOS devices. In addition, significant differences in implementation across different brands and versions of Android systems lead to serious compatibility issues when installing the dedicated app, requiring users to manually configure it, resulting in high learning costs and a poor user experience.

[0007] 2. Simultaneously configure a WiFi hotspot and 4G / 5G cellular communication modules on the IoT device. This allows the IoT device 200 to connect to the internet via its own cellular module while simultaneously activating the hotspot, enabling smart terminals to indirectly access the internet through this hotspot. While this solution extends network functionality, it suffers from high hardware costs, significantly increased power consumption, and a substantial decrease in battery life due to the need for the device to maintain dual network connections. Furthermore, cellular data usage on the IoT device is billed separately, increasing operating costs. Additionally, data transmission via the IoT device introduces extra network latency.

[0008] 3. This solution adopts a software-defined network architecture, deploying an SDN controller to uniformly manage heterogeneous networks and achieving automatic network discovery and switching based on protocols such as Hotspot 2.0. However, this solution requires dedicated network infrastructure investment and is only suitable for specific enterprise network environments. It cannot address the application needs of independent IoT devices (200) directly connecting to conventional smart terminals such as mobile phones and tablets (100), thus its applicability is significantly limited. Summary of the Invention

[0009] The purpose of this invention is to provide a communication method that allows for seamless dual-channel operation of WiFi and cellular networks. This method can construct dual channels that operate in parallel, enabling low-latency, high-bandwidth local data interaction tasks through the WiFi network channel while maintaining real-time connectivity with internet cloud services through the cellular network channel. Furthermore, it does not require the installation of any app or the acquisition of root privileges for system settings.

[0010] To achieve the above objectives, the present invention provides the following technical solution:

[0011] A method for parallel communication using both WiFi and cellular seamless dual-channel communication is provided, comprising the following steps:

[0012] Enable AP mode on IoT devices to generate WiFi hotspots and configure deceptive DHCP parameters on IoT devices;

[0013] Injecting an empty default route into the kernel network stack of IoT devices;

[0014] Configure allow rules and drop rules based on the kernel network stack, so that the smart terminal and IoT device can communicate normally through the allow rules, and the smart terminal cannot access the Internet through the drop rules.

[0015] After the smart terminal connects to the IoT device via a WiFi hotspot, the IoT device executes a probe message response strategy based on the Internet access probe request, so that the smart terminal determines that it cannot connect to the Internet via the WiFi hotspot based on the execution result of the probe message response strategy.

[0016] This enables the smart terminal to automatically migrate the default route from the WiFi network interface to the cellular network interface, while retaining the local subnet route of the WiFi network interface. This allows the smart terminal to communicate with IoT devices via WiFi and to interact with the Internet via the cellular network, achieving dual-channel parallel communication.

[0017] Preferably, the deceptive DHCP parameter configuration includes gateway deception parameter configuration, and the gateway deception parameter configuration includes:

[0018] In the Router option of the DHCP Offer / Ack message, set the local IP address of the IoT device and do not enable any IP forwarding function on that local IP address; or, set a reserved address to ensure that the gateway address cannot be routed to the Internet.

[0019] Preferably, the deceptive DHCP parameter configuration further includes DNS deception parameter configuration, and the DNS deception parameter configuration includes setting a local loopback address or an invalid address reserved by IANA in the DNS server option of the DHCP message.

[0020] Preferably, injecting an empty default route into the kernel network stack of an IoT device includes the following steps:

[0021] Configure a kernel routing table in the operating system kernel network stack of IoT devices, while retaining local subnet routes;

[0022] An empty default route is injected into the kernel routing table to point the next hop to a kernel null device or an unreachable reserved address, thereby setting the default gateway to empty.

[0023] Preferably, the empty default route is equivalent to the following command line: ip route add default dev null0, or ip route add default via 192.0.2.1 dev lo.

[0024] Preferably, the allow rule is equivalent to the following iptables command line: iptables -A FORWARD-d192.168.43.0 / 24-j ACCEPT.

[0025] Preferably, the drop rule is equivalent to the following iptables command line: iptables -A FORWARD !-d192.168.43.0 / 24-j DROP.

[0026] Preferably, the access probe request is automatically sent to the IoT device based on the smart terminal's operating system.

[0027] Preferably, the strategy for executing probe message responses includes:

[0028] The IoT device directly discards TCP SYN packets for access probe requests through firewall rules or a local proxy.

[0029] And / or, the IoT device delays its response to the access probe request, causing the smart terminal to determine that its WiFi network connection with the IoT device has timed out.

[0030] And / or, the IoT device returns an HTTP status code indicating a network connection error.

[0031] Preferably, if the IoT device enables IPv4 / IPv6 dual stack, then the following command line for a null IPv6 route is synchronously injected into the kernel routing table: ip -6 route add default dev null0.

[0032] In summary, the present invention has the following advantages compared with the prior art:

[0033] This invention can physically isolate local communication from the Internet to improve data security. It can also build a dual-channel system that supports both WiFi and cellular networks. This allows for low-latency, high-bandwidth local data interaction through the WiFi network channel while maintaining a real-time connection with Internet cloud services through the cellular network channel. The two channels do not compete for bandwidth or introduce latency between each other. Furthermore, this invention can achieve rapid and seamless network switching. This process is highly stable, unaffected by network fluctuations, and requires no app installation or root access for system settings.

[0034] Meanwhile, this invention can be implemented based on the smart terminal's own cellular network module and the IoT device's own AP mode, without the need for additional components, which can significantly reduce overall power consumption. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the communication architecture in this invention;

[0036] Figure 2 This is a flowchart illustrating the steps of the parallel communication method using WiFi and cellular non-sensory dual channels in this invention.

[0037] Figure 3 This diagram illustrates the data interaction between the smart terminal, IoT device, and cellular network when implementing the method of the present invention. Detailed Implementation

[0038] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0039] Example 1

[0040] like Figure 1-2 As shown, this embodiment provides a method for parallel communication using both WiFi and cellular seamless dual-channel communication. Figure 1 This is a schematic diagram illustrating a scenario where the cellular network is blocked after a smart terminal connects to an IoT device's access point (AP) hotspot in the prior art. The communication architecture includes a smart terminal 100, an IoT device 200, and a cellular network 300 (the cellular network 300 includes a base station). The smart terminal 100 interacts with the IoT device 200 via a WiFi network and with the Internet via the cellular network 300. In this embodiment, the smart terminal 100 includes, but is not limited to, mobile phones, tablets, PCs, and wearable smart devices. The IoT device 200 includes, but is not limited to, infrared thermal imagers, drones, vehicles, smart medical devices, smart home devices, and virtual reality devices (such as VR / AR / MR devices).

[0041] In existing technologies, such as Figure 1 As shown, when the smart terminal 100 connects to the IoT device 200 (such as a thermal imager) via a WiFi hotspot for RTSP real-time image transmission, the operating system of the smart terminal 100 automatically disconnects the cellular network (such as 5G / 4G network), and all network traffic is routed to the WiFi interface. Since the IoT device 200 itself does not provide internet access, the smart terminal 100 cannot access the internet, and the network-dependent AI assistant (smart assistant) running on it becomes unavailable because it cannot connect to the cloud server (e.g., Figure 1 The intelligent assistant area in the middle shows that AI cannot be used), which creates a technical contradiction that local image transmission and external network AI services cannot be obtained at the same time.

[0042] Based on this, such as Figure 2 As shown, the parallel communication method of WiFi and cellular seamless dual-channel communication provided in this embodiment includes the following steps:

[0043] S1. Start the AP (Access Point) mode of IoT device 200 to generate a WiFi hotspot for smart terminal 100 to connect to, and perform deceptive DHCP (Dynamic Host Configuration Protocol) parameter configuration on IoT device 200 so that the operating system of smart terminal 100 has the network configuration to connect to the Internet, but cannot access the Internet through the network configuration.

[0044] The deceptive DHCP parameter configuration includes gateway deception parameter configuration and DNS deception parameter configuration. Further, the gateway deception parameter configuration includes:

[0045] In the Router option (Option 3) of the DHCP Offer / Ack message, set the local IP address of IoT device 200 (e.g., 192.168.43.1) and do not enable any IP forwarding function on this local IP address; or, set a reserved address to ensure that the gateway address cannot be routed to the Internet in any network environment. For example, in this embodiment, the reserved address includes the TEST-NET-1 reserved address specified in RFC 5737 (e.g., 192.0.2.1), etc.

[0046] The DNS spoofing parameter configuration includes:

[0047] In the DNS server option (Option 6) of the DHCP message, set the local loopback address (127.0.0.1) or an invalid address reserved by IANA (Internet Assigned Numbers Authority) so that the smart terminal 100 cannot resolve any external domain name through this DNS server;

[0048] In addition, to ensure the basic functions of the WiFi hotspot are implemented, this embodiment requires standard DHCP service configuration for the WiFi hotspot, such as enabling the 802.11 b / g / n / ac protocol, configuring SSID broadcasting, WPA2-PSK / WPA3-SAE encryption and pre-shared keys, and establishing a Layer 2 wireless connection; and configuring the IP address pool by allocating a private Class C network segment (such as 192.168.43.0 / 24) to ensure rapid IP address recycling, etc.

[0049] Therefore, this embodiment uses the above-mentioned standard DHCP service configuration and deceptive DHCP (Dynamic Host Configuration Protocol) parameter configuration to make the network configuration obtained by the smart terminal 100 from the DHCP service formally complete and meet the basic judgment conditions of the operating system for connected networks, but in reality, it cannot access the Internet through the network configuration, thus laying the parameter basis for subsequent induced handover operations.

[0050] S2. An empty default route is injected into the kernel network stack of IoT device 200 to set the default route to empty. And, based on the Netfilter framework of the kernel network stack, allow rules and drop rules are configured so that the smart terminal 100 connected through WiFi hotspot and IoT device 200 can communicate normally through the allow rules, and the smart terminal 100 connected through WiFi hotspot cannot access the Internet through the drop rules.

[0051] Specifically, an empty default route is injected into the kernel network stack of IoT device 200 to set the default route (DefaultRoute) to null, including the following steps:

[0052] Configure a kernel routing table (i.e., ip route add 192.168.43.0 / 24 dev wlan0) in the network stack of the operating system kernel of IoT device 200, and retain the local subnet route to ensure that data packets whose destination IP belongs to this subnet can be forwarded normally through the wireless interface, so that smart terminal 100 and IoT device 200 can communicate locally.

[0053] An empty default route (prefix 0.0.0.0 / 0) is injected into the kernel routing table to point the next hop to a kernel null device or an unreachable reserved address (such as the IANA reserved test address (192.0.2.1)). This sets the default gateway to null, blocking all outbound traffic from unmatched directly connected subnets. Furthermore, the empty default route is equivalent to the following command line: ip routeadd default dev null0, or ip route add default via 192.0.2.1 dev lo, where null0 is a kernel null interface, and any packets sent to this interface are silently dropped; 192.0.2.1 is a test network segment reserved by IANA to ensure physical unreachability.

[0054] Furthermore, the allow rule is equivalent to the following iptables command line: `iptables -A FORWARD -d192.168.43.0 / 24 -j ACCEPT`, to allow data packets in the local subnet segment to pass through, enabling packet flow and allowing normal communication between the smart terminal 100 and the IoT device 200, ensuring the normal operation of local services (i.e., data transmission between the smart terminal 100 and the IoT device 200); the drop rule is equivalent to the following iptables command line: `iptables -A FORWARD !-d192.168.43.0 / 24 -j`. DROP is used to ensure that no ICMP error messages (such as DestinationUnreachable) are generated, so that all traffic forwarded by the smart terminal 100 based on the IoT device 200 to the external network is silently dropped, ensuring that the smart terminal 100 connected to the IoT device 200 cannot access the Internet; furthermore, this embodiment uses the DROP strategy instead of REJECT, so that the smart terminal 100 behaves as a connection timeout rather than explicitly receiving a rejection response (Timeout), which is closer to the characteristics of real network failure and enhances the authenticity of the deception;

[0055] Therefore, this embodiment can build a dual-rule isolation system of "local access and external network blocking" through the kernel routing layer and firewall layer to achieve the purpose of dual blocking of external network traffic. Furthermore, the FORWARD configuration based on the Netfilter framework provides corresponding access rules and drop rules to ensure that the smart terminal 100 cannot access the Internet through the WiFi hotspot without affecting local services.

[0056] S3. After the smart terminal 100 connects to the IoT device 200 via a WiFi hotspot, the IoT device 200 executes a probe message response strategy based on the Internet access probe request (i.e., HTTP / HTTPS probe request) sent by the smart terminal 100, so that the operating system of the smart terminal 100 determines that the smart terminal 100 cannot connect to the Internet via a WiFi hotspot based on the execution result of the probe message response strategy.

[0057] The access probe request can be automatically sent to the IoT device 200 based on the operating system of the smart terminal 100. For example, if the operating system of the smart terminal 100 is iOS, then the iOS system will automatically initiate HTTP / HTTPS probe requests to addresses such as captive.apple.com and www.apple.com; if the operating system is Android, then the Android system will automatically initiate probe requests to addresses such as connectivitycheck.gstatic.com, clients3.google.com, wifi.vivo.com.cn, and conn1.oppomobile.com.

[0058] Furthermore, the strategy for executing probe message responses includes:

[0059] The IoT device 200 directly discards the TCP SYN packet of the access probe request (i.e., "packet drop") through firewall rules or local proxy. When the iOS system and Android system send an Internet access probe request, they need to send a TCP SYN packet first to establish a TCP connection with the server. Therefore, in this embodiment, the IoT device 200 can make the TCP handshake fail (SYN packet no response) by directly discarding the TCP SYN packet, and further make the operating system of the smart terminal 100 determine that there is no network connection between the smart terminal 100 and the IoT device 200.

[0060] And / or, the IoT device 200 responds to the access probe request with a delay. For example, if the access probe request is sent for more than 10 seconds, it returns "connection timeout" (i.e. "delay"), which further enables the operating system of the smart terminal 100 to determine that the WiFi network connection between it and the IoT device 200 has timed out.

[0061] And / or, the IoT device 200 returns an HTTP status code (i.e., "this packet") indicating a network connection error. For example, in this embodiment, the HTTP status code indicating a network connection error includes non-200 status codes such as "returning 204 but payload error", which further causes the operating system of the smart terminal 100 to determine that the access probe request sent by the smart terminal 100 has failed, and the smart terminal 100 cannot connect to the Internet based on the WiFi hotspot.

[0062] Therefore, after the smart terminal 100 and IoT device 200 establish a WiFi hotspot connection, this embodiment can use the Layered Routing Deception Architecture (LRDA) based on packet loss, delay, and packet modification to intervene in the network detection mechanism of the smart terminal operating system. This allows the smart terminal 100 to maintain a WiFi connection at the data link layer while determining at the network layer that the WiFi hotspot is not accessible to the Internet, thus providing a basis for the subsequent native cellular fallback strategy of the operating system.

[0063] S4. After repeating step S3 several times (e.g., 2-3 times), the operating system of the smart terminal 100 automatically migrates the default route from the WiFi network interface (wlan0) to the cellular network interface (e.g., rmnet_data0 in Android system or pdp_ip0 in iOS system), so that the smart terminal 100 and the Internet establish a cellular network connection through the cellular network 300, thereby realizing data interaction between the smart terminal 100 and the Internet.

[0064] Specifically, after repeating step S3 several times (e.g., 2-3 times), the operating system of the smart terminal 100 confirms that the WiFi network connection between the smart terminal 100 and the IoT device 200 has failed. At this time, the network scoring module of the operating system of the smart terminal 100 (e.g., NetworkMonitor in Android system, NWPathMonitor in iOS system) can mark the WiFi network between the smart terminal 100 and the IoT device 200 as "No Internet Access" within a predetermined time period (e.g., 3-10 seconds), and further switch to the cellular network interface to establish a cellular network connection between the smart terminal 100 and the Internet through the cellular network 300.

[0065] In addition, when the operating system of the smart terminal 100 automatically migrates the default route from the WiFi network interface to the cellular network interface, it only migrates the default route, while retaining the local subnet route of the WiFi network interface (such as 192.168.43.0 / 24). Therefore, the smart terminal 100 and the IoT device 200 can maintain a continuous WiFi connection.

[0066] S5. The smart terminal 100 and the IoT device 200 interact with each other via WiFi network. At the same time, the smart terminal 100 and the Internet interact with each other via cellular network 300 to achieve dual-channel parallel data transmission and interaction.

[0067] For example, such as Figure 3 As shown, the data interaction between the smart terminal 100 and the IoT device 200 (taking a thermal imager as an example) based on the WiFi network includes: the smart terminal 100 accessing the local API of the IoT device 200 to obtain data from the IoT device 200 (such as thermal imaging data from the thermal imager); debugging, firmware upgrades, and local control command interaction of the IoT device 200 based on the smart terminal 100; and the smart terminal 100 discovering local area network devices (such as smart home network configuration) based on multicast / broadcast traffic (such as mDNS). Furthermore, the aforementioned data interaction based on the WiFi network can be achieved by operating the APP on the smart terminal 100, binding the local communication socket to the WiFi network through system APIs (such as Android's Network.bindSocketToNetwork).

[0068] The data interaction between the smart terminal 100 and the Internet based on the cellular network 300 includes the smart terminal 100 accessing cloud AI analysis, map services, social applications, etc., and this data interaction method can be achieved by operating the APP on the smart terminal 100 to initiate network requests through the standard Socket interface, and the operating system can further automatically select the interface according to the destination IP, etc., and the method does not require the APP to modify the code.

[0069] Therefore, this embodiment can physically isolate local communication from the Internet through empty default route configuration to prevent IoT devices from becoming a springboard for network attacks, thereby improving data security. At the same time, it can build physically isolated and parallel dual channels to carry low-latency, high-bandwidth local data interaction tasks through the WiFi network channel, while maintaining real-time connection with Internet cloud services through the cellular network channel. Moreover, the two channels do not compete for bandwidth or introduce latency into each other.

[0070] Furthermore, this embodiment can utilize the native mechanism of the smart terminal operating system to achieve a fast and seamless network switching (i.e., the smart terminal 100's operating system automatically migrates the default route from the WiFi network interface to the cellular network interface, thus establishing a cellular network connection between the smart terminal 100 and the Internet). This process is highly stable, unaffected by network environment fluctuations, and requires no APP installation or root access for system settings, achieving zero-intrusive deployment. It is also applicable to smart terminals with iOS and Android systems, achieving full platform compatibility.

[0071] Furthermore, this embodiment can be implemented based on the smart terminal's own cellular network module and the IoT device's own AP mode. After adopting this embodiment's solution, as follows... Figure 2As shown, while the smart terminal 100 transmits real-time RTSP images to the IoT device 200 via WiFi, it can also access the Internet normally via the cellular network 300. The AI ​​assistant (smart assistant) can connect to the cloud server normally and provide interactive services (such as...). Figure 2 The intelligent assistant area displays the normal dialogue interface, enabling simultaneous use of local image transmission and external AI assistant without the user's awareness.

[0072] Example 2:

[0073] The only difference between this embodiment and embodiment 1 is that in step S2, if the IoT device 200 enables IPv4 / IPv6 dual stack, the IPv6 null route command line is synchronously injected into the kernel routing table: ip -6 route add default devnull0, to prevent the smart terminal 100 from bypassing the IPv4 restriction through the IPv6 channel.

[0074] In summary, this invention can physically isolate local communication from the Internet through empty default route configuration to improve data security. At the same time, it can build a dual channel of WiFi and cellular network in parallel. While carrying low-latency, high-bandwidth local data interaction tasks through the WiFi network channel, it can maintain a real-time connection with Internet cloud services through the cellular network channel. Moreover, the two channels do not compete for bandwidth or introduce latency between each other.

[0075] Furthermore, this invention enables rapid and seamless network switching (i.e., the smart terminal's operating system automatically migrates the default route from the WiFi network interface to the cellular network interface). This process is highly stable, unaffected by network environment fluctuations, and requires no app installation or root access for system settings, thus achieving zero-intrusive deployment.

[0076] Meanwhile, this invention can be implemented based on the smart terminal's own cellular network module and the IoT device's own AP mode, without the need for additional components. Compared with the existing technology that sets up dual network cards on the device side, it can significantly reduce overall power consumption.

[0077] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for parallel communication using both WiFi and cellular seamless dual-channel communication, characterized in that, Includes the following steps: Enable AP mode on IoT devices to generate WiFi hotspots and configure deceptive DHCP parameters on IoT devices; Injecting an empty default route into the kernel network stack of IoT devices; Configure allow rules and drop rules based on the kernel network stack, so that the smart terminal and IoT device can communicate normally through the allow rules, and the smart terminal cannot access the Internet through the drop rules. After the smart terminal connects to the IoT device via a WiFi hotspot, the IoT device executes a probe message response strategy based on the Internet access probe request, so that the smart terminal determines that it cannot connect to the Internet via the WiFi hotspot based on the execution result of the probe message response strategy. This enables the smart terminal to automatically migrate the default route from the WiFi network interface to the cellular network interface, while retaining the local subnet route of the WiFi network interface. This allows the smart terminal to communicate with IoT devices via WiFi and to interact with the Internet via the cellular network, achieving dual-channel parallel communication.

2. The communication method as described in claim 1, characterized in that, The deceptive DHCP parameter configuration includes gateway deception parameter configuration, and the gateway deception parameter configuration includes: In the Router option of the DHCP Offer / Ack message, set the local IP address of the IoT device and do not enable any IP forwarding function on that local IP address; or, set a reserved address to ensure that the gateway address cannot be routed to the Internet.

3. The communication method as described in claim 1, characterized in that, The deceptive DHCP parameter configuration also includes DNS deception parameter configuration, and the DNS deception parameter configuration includes setting a local loopback address or an invalid address reserved by IANA in the DNS server option of the DHCP message.

4. The communication method as described in claim 1, characterized in that, Injecting an empty default route into the kernel network stack of an IoT device includes the following steps: Configure a kernel routing table in the operating system kernel network stack of IoT devices, while retaining local subnet routes; An empty default route is injected into the kernel routing table to point the next hop to a kernel null device or an unreachable reserved address, thereby setting the default gateway to empty.

5. The communication method as described in claim 4, characterized in that, The empty default route is equivalent to the following command line: iproute add default dev null0, or ip route add default via 192.0.2.1 dev lo.

6. The communication method as described in claim 1, characterized in that, The allow rule is equivalent to the following iptables command line: iptables -A FORWARD -d 192.168.43.0 / 24 -j ACCEPT.

7. The communication method as described in claim 1, characterized in that, The drop rule is equivalent to the following iptables command line: iptables -A FORWARD !-d 192.168.43.0 / 24 -j DROP.

8. The communication method as described in claim 1, characterized in that, The access probe request is automatically sent to the IoT device based on the smart terminal's operating system.

9. The communication method as described in claim 1, characterized in that, The strategy for executing probe message responses includes: The IoT device directly discards TCP SYN packets for access probe requests through firewall rules or a local proxy. And / or, the IoT device delays its response to the access probe request, causing the smart terminal to determine that its WiFi network connection with the IoT device has timed out. And / or, the IoT device returns an HTTP status code indicating a network connection error.

10. The communication method as described in claim 4, characterized in that, If the IoT device enables IPv4 / IPv6 dual stack, then inject the IPv6 null route command line into the kernel routing table synchronously: ip -6 route add default dev null0.

Images