IP address same network verification method, device, equipment and medium

Abstract

The application relates to an IP address same-network verification method and device, equipment and a medium, and is applied to the technical field of computer network communication. The method comprises the following steps: obtaining a candidate IP address of a target device via an out-of-band channel; obtaining dynamic host configuration protocol (DHCP) information of a current network connection of a client device to construct a main network snapshot; when the client IP address or the first subnet mask is a null value or a zero value, determining that the main network snapshot is invalid; in response to the main network snapshot being determined as invalid, constructing a bottom network snapshot based on the local IP address of the client device and a preset second subnet mask; judging whether the candidate IP address and the IP address of the client device are in the same network subnet; based on the judgment result, when it is judged that the candidate IP address and the IP address of the client device are in the same network subnet, direct connection to the candidate IP address is allowed, and when it is judged that the candidate IP address and the IP address of the client device are not in the same network subnet, direct connection to the candidate IP address is prevented. The application has the effect of improving the accuracy of same-network verification.

Description

Technical Field

[0001] This application relates to the technical field of computer network communication, and in particular to a method, apparatus, device and medium for verifying IP addresses on the same network. Background Technology

[0002] In modern network applications, such as wireless screen mirroring and fast file transfer, it is usually necessary for two devices (e.g., a mobile phone as the client and a large TV screen as the target device) to be on the same local area network to achieve an efficient and stable direct connection. To establish a connection, the client device first needs to obtain the IP address of the target device.

[0003] A common approach is to quickly transmit the target device's IP address via out-of-band channels (such as sound waves or QR codes) independent of the main data network. However, simply obtaining the IP address is insufficient. Due to the complexity of network environments, the IP address may belong to a different network subnet than the client device; for example, the client might be connected to a company's guest Wi-Fi, while the target device is connected to internal office Wi-Fi. In such cross-network segment scenarios, directly attempting to connect using the IP address will not only fail but also incur unnecessary network overhead and user downtime.

[0004] To address this issue, existing technologies typically perform a network compatibility check before connection. A typical method for this check is for the client to obtain its own network information (IP address and subnet mask) and combine it with the target device's IP address to calculate whether they belong to the same network segment. In practice, the client usually attempts to obtain this information from its network connection's Dynamic Host Configuration Protocol (DHCP) service.

[0005] However, this reliance on DHCP information has significant drawbacks. On certain operating systems (such as some versions of Android) or in specific network environments, client devices may fail to obtain complete DHCP information; for example, the obtained subnet mask (i.e., the first subnet mask) may be empty or zero. In this case, the network state description based on DHCP information (i.e., the primary network snapshot) is invalid, making it impossible to determine if the device is on the same network. If the connection is abandoned immediately, a potentially successful connection opportunity will be missed; if a connection is attempted blindly without judgment, the aforementioned problem of failed cross-network connection attempts will recur. Therefore, existing technologies lack a reliable fallback mechanism for verifying the same network when client network information is incomplete. Summary of the Invention

[0006] To address the technical problem of low accuracy in same-network verification due to incomplete client network information in existing technologies, this application provides a method, apparatus, device, and medium for IP address same-network verification.

[0007] Firstly, this application provides a method for verifying IP address compatibility on the same network, employing the following technical solution: A method for verifying IP addresses on the same network includes: Obtain the candidate IP address of the target device via out-of-band channels; Obtain Dynamic Host Configuration Protocol (DHCP) information for the current network connection of the client device to construct a primary network snapshot. The DHCP information includes the client IP address and the first subnet mask. If the client IP address or the first subnet mask is empty or zero, the main network snapshot is determined to be invalid. In response to the primary network snapshot being determined to be invalid, a fallback network snapshot is constructed based on the client device's local IP address and a preset second subnet mask; Using the valid subnet mask determined by the primary network snapshot or the fallback network snapshot, it is determined whether the candidate IP address and the IP address of the client device are in the same network subnet; Based on the judgment result, if it is determined that the candidate IP address is in the same network subnet, a direct connection is allowed; if it is determined that the candidate IP address is not in the same network subnet, a direct connection is blocked.

[0008] Optionally, the out-of-band channel includes at least one of the following: an acoustic channel, a QR code channel, a Bluetooth channel, and a near-field communication (NFC) channel.

[0009] Optionally, the step of attempting to obtain DHCP information includes: Obtain the DHCP information of the wireless or wired network currently connected to the client device, and perform byte order correction on the obtained DHCP information.

[0010] Optionally, the step of obtaining the local IP address of the client device includes: Iterate through the network interfaces of the client device to obtain the non-loopback IP address that matches the current network connection type.

[0011] Optionally, the preset second subnet mask is 255.255.255.0.

[0012] Optionally, the step of determining whether they are in the same network subnet includes: Using the effective subnet mask, perform bitwise AND operations on the candidate IP address and the IP address of the client device, respectively; And compare the results of the two bitwise AND operations. If they are the same, they are determined to be in the same subnet.

[0013] Optionally, the method further includes: In response to blocking direct connections to the candidate IP address, an alternative connection procedure is executed, the alternative connection procedure including at least the following: The system prompts the user to switch networks; initiates a connection process based on the screen mirroring code; or waits for the connection result based on the network service discovery mechanism.

[0014] Secondly, this application provides an IP address same-network verification device, which adopts the following technical solution: An IP address same-network verification device, comprising: The candidate address acquisition module is used to acquire the candidate IP address of the target device via an out-of-band channel; The main snapshot building module is used to obtain Dynamic Host Configuration Protocol (DHCP) information of the current network connection of the client device in order to build a main network snapshot. The DHCP information includes the client IP address and the first subnet mask. The snapshot invalidity determination module is used to determine that the main network snapshot is invalid when the client IP address or the first subnet mask is empty or zero. The fallback snapshot construction module is used to construct a fallback network snapshot based on the local IP address of the client device and a preset second subnet mask in response to the main network snapshot being determined to be invalid. The network subnet determination module is used to determine whether the candidate IP address and the IP address of the client device are in the same network subnet by using a valid subnet mask determined by the main network snapshot or the fallback network snapshot; The direct connection blocking module is used to, based on the result of the judgment, allow direct connection to the candidate IP address when it is determined that the IP address is in the same network subnet, and block direct connection to the candidate IP address when it is determined that the IP address is not in the same network subnet.

[0015] Thirdly, this application provides an electronic device that adopts the following technical solution: An electronic device includes a processor coupled to a memory; The processor is configured to execute a computer program stored in the memory, so that the electronic device executes the computer program of the IP address same-network verification method according to any one of the first aspects.

[0016] Fourthly, this application provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium storing a computer program capable of being loaded by a processor and executing the IP address network authentication method described in any of the first aspects.

[0017] In summary, this application includes at least one of the following beneficial technical effects: 1. Improved reliability and success rate of network compatibility verification. By introducing a fallback network snapshot mechanism, this invention can still perform effective network compatibility judgment even when client DHCP information is missing or invalid. This avoids misjudging connectable devices as unconnectable due to incomplete information, significantly improving the connection success rate in complex network environments.

[0018] 2. Enhanced network connection security and efficiency. This invention performs pre-processing verification of candidate IP addresses within the same network, forming control logic to allow / block direct connections. This effectively prevents blind connection attempts to IP addresses in different subnets, reducing unnecessary network overhead and connection timeouts, and avoiding potential security risks.

[0019] 3. Improved user experience. When the connection is detected as a different network, this invention can trigger alternative connection processes, such as prompting the user to switch networks or use a screen mirroring code, providing clear guidance and alternative solutions rather than simply indicating a connection failure. This forms a complete interactive loop and enhances the overall user experience of the product.

[0020] 4. Provides clear decision-making basis. The verification process of this invention provides a recordable and traceable basis for connection decisions, which helps in subsequent log analysis, problem investigation and continuous optimization of connection strategies. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating an IP address same-network verification method provided in an embodiment of the present invention.

[0022] Figure 2 This is a structural block diagram of an IP address same-network verification device provided in an embodiment of the present invention.

[0023] In the attached diagram: 801 is the candidate address acquisition module, 802 is the main snapshot construction module, 803 is the snapshot invalidation determination module, 804 is the fallback snapshot construction module, 805 is the network subnet determination module, 806 is the direct connection blocking module; 9 is an electronic device; 10 is a computer-readable storage medium. Detailed Implementation

[0024] To better understand the technical solution of the present invention, the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0025] In applications such as wireless screen mirroring and fast file transfer between devices, client devices (such as smartphones) often need to establish direct network connections with target devices (such as smart TVs or other mobile phones) within the local area network. To improve connection success rate and speed, client devices need to quickly and accurately determine whether they are on the same network subnet as the target device before initiating a connection, i.e., whether the network is reachable. A common method is to obtain the target device's IP address through out-of-band channels such as sound waves or QR codes, and then perform network identity verification. However, in practice, especially on mobile operating systems such as Android, it is unreliable for client devices to obtain their complete network configuration information (especially the subnet mask). System APIs (Applicator Programming Interfaces) may sometimes fail to return the subnet mask assigned by the DHCP server, or return an invalid zero value. This lack of information can cause the network identity verification logic to malfunction, potentially incorrectly blocking a connection that could have been established (false negative), or attempting to connect when it shouldn't be (false positive), thus reducing user experience and connection stability.

[0026] To address the aforementioned technical problems, this invention proposes a dual-protection method for IP address verification within the same network. The core idea of ​​this method is to prioritize using a "primary network snapshot" obtained from DHCP information for verification; if this snapshot is invalid due to incomplete information, it automatically switches to using a preset, conservative "fallback network snapshot." This combined primary and backup strategy significantly improves the robustness and accuracy of network verification in various complex network environments.

[0027] In the context of this invention, for clarity, some key terms will first be explained. The "candidate IP address" refers to an IP address obtained from a target device via a specific channel, intended to verify its network reachability. For example, an IP address obtained by decoding a sound wave signal or scanning a QR code. Before verification, this address is only a "candidate" and cannot be directly used to establish a connection. The "primary network snapshot" refers to a network state description constructed based on DHCP information of the client device's current network connection. Specifically, it mainly includes the client device's own IP address and first subnet mask obtained from the DHCP server via standard system API. Ideally, this is a complete and accurate network state description. The "fallback network snapshot" is a backup network state description activated when the primary network snapshot is invalid. When the system determines that a valid client IP address or first subnet mask cannot be obtained from the DHCP information, it will instead obtain the client's local IP address and combine it with a preset second subnet mask to construct this snapshot. This design aims to provide a conservative but reliable basis for judgment when information is incomplete.

[0028] like Figure 1 As shown, this embodiment of the invention provides a method for verifying IP addresses on the same network. The method first obtains candidate IP addresses of the target device via an out-of-band channel. This step is the starting point of the entire verification process, providing the target object for subsequent judgments. Next, the method attempts to obtain Dynamic Host Configuration Protocol (DHCP) information of the client device's current network connection to construct a primary network snapshot. Ideally, the DHCP information should include the client device's IP address and a first subnet mask assigned by the network. This step aims to utilize the most accurate network source information for judgment. However, considering the complexity of real-world network environments, the method includes a crucial judgment step: if the client IP address or the first subnet mask is null or zero, the primary network snapshot is determined to be invalid. For example, on some Android devices or in specific network environments, the obtained subnet mask might be 0.0.0.0. This judgment step enables the method to identify incomplete information, avoiding decisions based on erroneous or missing data.

[0029] In response to the primary network snapshot being deemed invalid, the method initiates a fallback mechanism, namely, constructing a fallback network snapshot based on the client device's local IP address and a preset second subnet mask. This step is one of the core innovations of this invention, providing a reliable backup solution to ensure that the verification process can continue even when DHCP information is incomplete, rather than failing outright. After obtaining a valid network snapshot (whether primary or fallback), the method uses the valid subnet mask determined by the snapshot to determine whether the candidate IP address and the client device's IP address are in the same network subnet. This step is the core computational step of the same-network verification. Finally, based on the result of the determination, connection control logic is executed. When it is determined that they are in the same network subnet, a direct connection to the candidate IP address is allowed; when it is determined that they are not in the same network subnet, a direct connection to the candidate IP address is blocked. This design directly transforms the result of the same-network verification into control logic for allowing / blocking direct connections, achieving precise control over connection behavior and preventing resource waste and connection failures caused by blind cross-network connections.

[0030] Based on the above scheme, the out-of-band channel can take various forms. Specifically, the out-of-band channel includes at least one of the following: an acoustic channel, a QR code channel, a Bluetooth channel, and a Near Field Communication (NFC) channel. For example, a client device can obtain a candidate IP address by receiving and decoding the acoustic signal emitted by the target device through a microphone, or it can scan a QR code displayed on the target device's screen using a camera. The versatility of this design allows the present invention to be applied to diverse device discovery and connection scenarios.

[0031] As a specific implementation method, byte order correction is required during the process of attempting to obtain DHCP information to ensure data accuracy. For example, on some Android system platforms, the IP address obtained through the API may be a little-endian integer, while the standard network byte order is big-endian. Without correction, directly using it for calculations will lead to completely incorrect results. Therefore, after obtaining DHCP information, performing byte order correction on the obtained IP address, subnet mask, and other values ​​is a crucial step in ensuring the correctness of subsequent bitwise operations.

[0032] Accurately obtaining the local IP addresses of client devices is crucial when building a fallback network snapshot. Specifically, this step involves iterating through all network interfaces of the client device and filtering for non-loopback IP addresses that match the current network connection type (e.g., Wi-Fi, Ethernet). For example, local loopback addresses like "127.0.0.1" and virtual network interface addresses built by VPNs or virtual machines need to be filtered out to ensure that the selected IP addresses are those actually used within the physical local area network. This step provides a solid data foundation for building a reliable fallback network snapshot.

[0033] Preferably, the preset second subnet mask is 255.255.255.0. This value is chosen because it corresponds to the / 24 network prefix, which is the most common subnetting method in the vast majority of homes, small offices, and public Wi-Fi networks. When the exact subnet mask is unavailable, using this most common value as a "conservative" fallback mask allows for correct judgment in the widest range of typical scenarios, achieving the optimal balance between security and availability when information is incomplete.

[0034] Specifically, the step of determining whether two IP addresses are in the same subnet is typically implemented using a bitwise AND operation. This step involves performing a bitwise AND operation on both the candidate IP address and the client device's IP address using the valid subnet mask (from the primary network snapshot or the fallback network snapshot). Then, the results of the two bitwise AND operations are compared. If the results are identical, it indicates that the two IP addresses have the same network prefix, meaning they are in the same subnet. This method is computationally efficient, logically clear, and well-suited for execution on resource-constrained mobile devices.

[0035] When the determination result indicates that the devices are not on the same network subnet and direct connection is blocked, the method of this invention further includes executing an alternative connection process to improve user experience. This process does not simply terminate the operation but provides guidance for the user to proceed. The alternative connection process may include at least one of the following: prompting the user on the interface to switch to the same Wi-Fi network as the target device; automatically or guiding the user to initiate a connection process based on a screen mirroring code or PIN code; or, while blocking direct IP connection, continuing to wait for a connection result based on a Network Service Discovery (NSD) mechanism (such as mDNS, MulticastDNS). In this way, even if the user is on the wrong network, they receive clear guidance instead of facing an unresponsive failure, thus significantly improving the user experience.

[0036] To more clearly illustrate the technical solution of the present invention, a detailed description is provided below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0037] In one implementation scenario, we consider the case where the primary network snapshot is valid. A user's client device (a smartphone) connects to a well-configured home Wi-Fi network. When the screen mirroring application on the device launches, it requests network information from the DHCP server via the system API and successfully obtains the client IP address 192.168.1.10 and the first subnet mask 255.255.255.0. Based on this information, the system successfully constructs a valid primary network snapshot. Now, the user wants to mirror the screen to a smart TV in the living room. The smart TV broadcasts its candidate IP address, 192.168.1.20, via acoustic waves. The mobile application receives and decodes the acoustic waves to obtain this candidate IP address. Subsequently, the application uses the constructed primary network snapshot for judgment. It performs a bitwise AND operation between the subnet mask 255.255.255.0 and both the client IP address 192.168.1.10 and the candidate IP address 192.168.1.20; the result of both operations is 192.168.1.0. Since the results are the same, the system determines that the two are in the same network subnet, and therefore allows a direct connection to the candidate IP address, thus quickly establishing screen mirroring.

[0038] In another implementation scenario, we consider a situation where the primary network snapshot is invalid, requiring a fallback mechanism. A user's client device connects to a public Wi-Fi network. Due to network environment or device compatibility issues, when the screen mirroring application attempts to obtain DHCP information, although it obtains the client IP address 172.20.10.15, the first subnet mask is 0.0.0.0. According to the method of this invention, the system determines that the primary network snapshot containing the zero-value subnet mask is invalid. At this point, the fallback mechanism is activated. The system then verifies that the currently active, physical IP address is indeed 172.20.10.15 by traversing network interfaces. Then, the system uses a preset second subnet mask of 255.255.255.0 to construct a fallback network snapshot with this IP address. Next, the client device scans a QR code on a nearby display device to obtain its candidate IP address, 172.20.10.88. The system uses the subnet mask 255.255.255.0 from the fallback network snapshot for judgment. Calculation shows that (172.20.10.15 & 255.255.255.0) results in 172.20.10.0, and (172.20.10.88 & 255.255.255.0) also results in 172.20.10.0. Since the results are the same, it is determined to be on the same network. Therefore, even in the case of missing initial DHCP information, the method of this invention can still correctly determine and allow the connection, avoiding functional failures caused by limitations of the system API.

[0039] In some scenarios, client devices and target devices may be physically adjacent but logically isolated in networks. For example, in an office environment, a user is in conference room A, and their client device is connected to the conference room's Wi-Fi, obtaining an IP address of 192.168.1.10. Assuming the DHCP information is incomplete, the system constructs a fallback network snapshot based on IP 192.168.1.10 and a second subnet mask of 255.255.255.0. Simultaneously, due to poor sound insulation, the user's client device receives an audio signal from a smart TV in the adjacent conference room B. After decoding, the candidate IP address is 192.168.2.20. This is because conference room B uses a separate subnet. At this point, the system uses the fallback network snapshot for judgment. It performs a bitwise AND operation between the subnet mask 255.255.255.0 and both the client IP 192.168.1.10 and the candidate IP address 192.168.2.20. The first calculation yielded 192.168.1.0, and the second yielded 192.168.2.0. Since the two results are different, the system determines that they are not on the same network subnet. According to the method of the present invention, the system will block direct connections to the candidate IP address 192.168.2.20. This step is crucial because it prevents the client from making a futile connection request to an unreachable IP address, saving time and system resources, and avoiding potential user confusion. Furthermore, the system will execute an alternative connection procedure. For example, a prompt box will pop up on the phone screen stating: "The target device may be on another network (192.168.2.x). Please check and switch to the correct Wi-Fi network and try again." This user-friendly prompt transforms a potential technical glitch into clear user guidance, greatly improving the user experience.

[0040] The method of this invention is not limited to obtaining candidate IP addresses via acoustic channels. In another embodiment, the target device (e.g., a television in a hotel room) can display a dynamically generated QR code on its welcome screen. This QR code encodes the television's current candidate IP address. The user scans this QR code using an application on their client device (smartphone). The decoder within the application parses the QR code image and extracts the candidate IP address contained within. Here, the QR code and its scanning process constitute the out-of-band channel. After obtaining the candidate IP address, the subsequent same-network verification process is exactly the same as in the aforementioned embodiment. The client device constructs a primary network snapshot or a fallback network snapshot, performs subnet comparison, and ultimately decides whether to allow or block the connection and initiate the alternative connection process. This example illustrates the versatility of the core verification logic of this invention; it can be combined with any out-of-band channel technology capable of transmitting IP addresses, exhibiting strong scalability.

[0041] To more fully illustrate the embodiments of the present invention, the following description will be provided in conjunction with the accompanying drawings. Figure 1 and attached Figure 2 The following description uses a smartphone as an example of electronic device 9. This electronic device 9 is a typical carrier of the technical solution of the present invention.

[0042] like Figure 2 As shown, the present invention also provides an IP address same-network verification device, which can be integrated into the electronic device 9, for example, as a software module or hardware circuit within it. The device includes: a candidate address acquisition module 801, a primary snapshot construction module 802, a snapshot invalidation determination module 803, a fallback snapshot construction module 804, a network subnet determination module 805, and a direct connection blocking module 806. The electronic device 9, such as a smartphone, includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, enables the electronic device 9 to implement the aforementioned IP address same-network verification method. The functions of each module of the device can be implemented by different code segments of the computer program.

[0043] Specifically, the candidate address acquisition module 801 is responsible for acquiring candidate IP addresses of the target device via out-of-band channels. For example, it can call the phone's microphone hardware and audio processing library to decode sound wave signals, or call the camera hardware and image recognition library to parse QR codes. The main snapshot construction module 802 is responsible for calling the operating system's network management API to obtain the DHCP information of the currently connected Wi-Fi or Ethernet, including the client IP address and the first subnet mask, and performing necessary byte order corrections to attempt to build the main network snapshot. The snapshot invalidity determination module 803 receives the output of the main snapshot construction module 802 and checks the IP address and subnet mask fields. If any field is found to be empty or represents an invalid zero value (such as 0.0.0.0), it determines that the main network snapshot is invalid and triggers a fallback process. Upon receiving the invalidity determination signal, the fallback snapshot construction module 804 is activated. It finds a reliable local IP address by traversing the system's network interface list and filtering virtual and loopback interfaces. Then, it combines this IP address with a preset second subnet mask (e.g., 255.255.255.0) to form a fallback network snapshot. The network subnet determination module 805 is the core calculation unit. It receives candidate IP addresses from the candidate address acquisition module 801 and valid network snapshots from the main snapshot construction module 802 or the fallback snapshot construction module 804. It then performs the aforementioned bitwise AND operation and compares the results, outputting a Boolean value indicating whether the network is on the same network. The direct connection blocking module 806, as the final executor, makes a decision based on the output of the network subnet determination module 805. If the result is "yes" (same network), it allows the connection request; if the result is "no" (different network), it blocks the connection request and may selectively notify the UI module to initiate an alternative connection process.

[0044] Reference Figure 1 and Figure 2A complete workflow is as follows: The user opens the screen mirroring application on their smartphone, and the application instructs the candidate address acquisition module 801 to start working. The module obtains the candidate IP address of the TV as 192.168.0.100 via sound waves. Simultaneously, the main snapshot construction module 802 attempts to obtain DHCP information, but returns a subnet mask of 0. The snapshot invalidity determination module 803 determines that the main snapshot is invalid. The fallback snapshot construction module 804 starts, discovers the phone's local IP as 192.168.0.15, and constructs a fallback network snapshot using a second subnet mask of 255.255.255.0. The network subnet determination module 805 receives the candidate IP address 192.168.0.100 and the fallback network snapshot. It performs the calculation: (192.168.0.15 & 255.255.255.0) yields 192.168.0.0, and (192.168.0.100 & 255.255.255.0) also yields 192.168.0.0. The results are identical. This judgment result is sent to the direct connection blocking module 806. Module 806 allows the connection accordingly, and the application successfully establishes a connection with the television. The entire process is automated, fast, and reliable, effectively solving the pain points of existing technologies.

[0045] The present invention also provides a computer-readable storage medium 10 having a computer program or instructions stored thereon. When these programs or instructions are executed on a computer or similar electronic device, they enable the computer or electronic device to perform an IP address network authentication method. This medium can be any form of non-transitory storage medium, such as flash memory, hard disk, or optical disk.

[0046] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for verifying IP address compatibility on the same network, characterized in that, include: Obtain the candidate IP address of the target device via out-of-band channels; Obtain Dynamic Host Configuration Protocol (DHCP) information for the current network connection of the client device to construct a primary network snapshot. The DHCP information includes the client IP address and the first subnet mask. If the client IP address or the first subnet mask is empty or zero, the main network snapshot is determined to be invalid. In response to the primary network snapshot being determined to be invalid, a fallback network snapshot is constructed based on the client device's local IP address and a preset second subnet mask; Using the valid subnet mask determined by the primary network snapshot or the fallback network snapshot, it is determined whether the candidate IP address and the IP address of the client device are in the same network subnet; Based on the judgment result, if it is determined that the candidate IP address is in the same network subnet, a direct connection is allowed; if it is determined that the candidate IP address is not in the same network subnet, a direct connection is blocked.

2. The method according to claim 1, characterized in that, The out-of-band channels include at least one of the following: acoustic channel, QR code channel, Bluetooth channel, and NFC channel.

3. The method according to claim 1, characterized in that, The steps for attempting to obtain DHCP information include: Obtain the DHCP information of the wireless or wired network currently connected to the client device, and perform byte order correction on the obtained DHCP information.

4. The method according to claim 1, characterized in that, The steps for obtaining the local IP address of the client device include: Iterate through the network interfaces of the client device to obtain the non-loopback IP address that matches the current network connection type.

5. The method according to claim 1, characterized in that, The preset second subnet mask is 255.255.255.

0.

6. The method according to claim 1, characterized in that, The step of determining whether they are in the same network subnet includes: Using the effective subnet mask, perform bitwise AND operations on the candidate IP address and the IP address of the client device, respectively; And compare the results of the two bitwise AND operations. If they are the same, they are determined to be in the same subnet.

7. The method according to claim 1, characterized in that, The method further includes: In response to blocking direct connections to the candidate IP address, an alternative connection procedure is executed, the alternative connection procedure including at least the following: The system prompts the user to switch networks; initiates a connection process based on the screen mirroring code; or waits for the connection result based on the network service discovery mechanism.

8. An IP address same-network verification device, characterized in that, include: The candidate address acquisition module is used to acquire the candidate IP address of the target device via an out-of-band channel; The main snapshot building module is used to obtain Dynamic Host Configuration Protocol (DHCP) information of the current network connection of the client device in order to build a main network snapshot. The DHCP information includes the client IP address and the first subnet mask. The snapshot invalidity determination module is used to determine that the main network snapshot is invalid when the client IP address or the first subnet mask is empty or zero. The fallback snapshot construction module is used to construct a fallback network snapshot based on the local IP address of the client device and a preset second subnet mask in response to the main network snapshot being determined to be invalid. The network subnet determination module is used to determine whether the candidate IP address and the IP address of the client device are in the same network subnet by using a valid subnet mask determined by the main network snapshot or the fallback network snapshot; The direct connection blocking module is used to, based on the result of the judgment, allow direct connection to the candidate IP address when it is determined that the IP address is in the same network subnet, and block direct connection to the candidate IP address when it is determined that the IP address is not in the same network subnet.

9. An electronic device, characterized in that, Includes a processor, which is coupled to a memory; The processor is configured to execute a computer program stored in the memory, causing the electronic device to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It includes a computer program or instructions that, when run on a computer, cause the computer to perform the method as described in any one of claims 1 to 7.

Images