VxWorks system network fault positioning method based on hierarchical diagnosis and cross validation

Abstract

The invention relates to a VxWorks system network fault positioning method based on hierarchical diagnosis and cross validation, and belongs to the technical field of embedded network fault diagnosis. The method is suitable for an embedded device of a VxWorks system to quickly distinguish a local network card fault and a remote switch fault in a network disconnection scene, and accurate diagnosis of a network fault in the VxWorks system is realized through layered fault isolation and cross validation of a physical layer, a link layer and a network device layer. The network fault diagnosis and positioning method provided by the invention is suitable for systems of various versions of VxWorks, the fault positioning accuracy of a physical layer can reach 98% or above, and the fault positioning accuracy of a driving layer can reach 96% or above.

Description

Technical Field

[0001] This invention belongs to the field of embedded network fault diagnosis technology, specifically relating to a method for locating network faults in VxWorks systems based on hierarchical diagnosis and cross-validation. Background Technology

[0002] Current VxWorks system network fault location methods have the following technical limitations: 1. Limited detection method: It only judges the fault by Ping delay and cannot distinguish between network card PHY damage and switch policy blocking; it relies on SNMP query, and this function is often disabled in industrial switches; 2. Insufficient diagnostic accuracy: Traditional methods (such as indicator light detection) have a false positive rate of >35%; they cannot locate chip-level faults (such as PHY clock crystal oscillator aging). 3. Poor real-time diagnostics: The whole machine restart test causes a service interruption time of more than 2 minutes.

[0003] Existing solutions lack the ability to isolate and verify layered faults at the physical layer, link layer, and network device layer in VxWorks systems, thus failing to accurately locate network faults in VxWorks systems. Summary of the Invention

[0004] (a) Technical problems to be solved The technical problem this invention aims to solve is: to provide a network fault location method for VxWorks systems based on hierarchical diagnosis and cross-validation, addressing the following issues in VxWorks systems: 1. The confusion between network card driver malfunctions and switch failures; 2. Ping detection is prone to misjudgment due to the influence of switch policies; 3. Issues with external network analyzers being unable to be deployed in embedded device environments; 4. The device logs lack physical layer status information.

[0005] (II) Technical Solution To address the aforementioned technical problems, this invention provides a VxWorks system network fault location method based on hierarchical diagnosis and cross-validation, comprising the following steps: S1: Detect the physical layer status of the network card of the embedded device in the VxWorks system; S2: Perform driver-level local loopback test; S3: Actively send an ARP request to the gateway and verify the response; S4: Switch port mirroring diagnostics, performing multi-dimensional verification of switch liveness; S5: Generates a fault location report based on the physical layer status, driver-level local loopback test results, ARP response results, and switch liveness verification results.

[0006] The present invention also provides a system for implementing the method.

[0007] The present invention also provides an embedded network fault diagnosis method based on the above method.

[0008] The present invention also provides an embedded network fault diagnosis system based on the aforementioned system.

[0009] (III) Beneficial Effects The innovation of this invention compared to traditional methods lies in: 1. For the first time, a layered closed-loop verification of "physical layer → link layer → switch" was achieved on an embedded device. 2. It pioneered the "cross-validation mechanism of physical layer state and ARP response" to solve the ambiguity of a single Ping test; 3. Non-intrusive switch diagnostics are achieved using programmable SNMP commands, requiring no additional hardware; 4. No need to actively send ARP requests; zero traffic overhead is achieved by passively analyzing existing caches.

[0010] This invention is applicable to embedded fields such as industrial control and network equipment, and can significantly improve the efficiency of network fault diagnosis in VxWorks systems. Detailed Implementation

[0011] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to examples.

[0012] This invention proposes a network fault location method for VxWorks systems based on hierarchical diagnosis and cross-validation. This method is applicable to embedded devices in VxWorks systems that can quickly distinguish between local network card faults and remote switch faults in network outage scenarios. By implementing hierarchical fault isolation and cross-validation at the physical layer, link layer, and network device layer, it achieves accurate diagnosis of network faults in VxWorks systems.

[0013] Only by adopting the solution of this invention can the technical pain points of current VxWorks system network fault location methods be effectively solved. The network fault diagnosis and location method proposed in this invention is applicable to all versions of VxWorks systems, with a physical layer fault location accuracy of over 98% and a driver layer fault location accuracy of over 96%.

[0014] This invention proposes a network fault location method for VxWorks systems based on hierarchical diagnosis and cross-validation, the steps of which are as follows: S1: Detect the physical layer status of the network card of the embedded device in the VxWorks system; S 11 Access the link status register of the PHY chip. (2) Access the address of the link status register of the PHY chip of the network card through the “miiTool (Media Independent Interface Tool)” driver interface provided by the VxWorks system; (2) Read the second bit of the link status register (LSB=0); if the value of this bit is "1", it means that there is a physical link connection between the network card and the switch (the network cable is inserted and the signal is normal); if the value of this bit is "0", it means that the physical link is disconnected (the network cable is not inserted or is damaged).

[0015] S 12 Signal quality diagnosis (1) Read the error counter register of the PHY chip; (2) Perform three consecutive samples (with a 1-second interval) and calculate the CRC error increment per second: (a) The first sampled value is denoted as C1; (b) After 1 second, the sampled value is recorded as C2 (C2>C1>0), and the CRC error increment per second ΔC1=C2-C1 is calculated; (c) After another 1-second interval, the sampled value is recorded as C3 (C3>C2>C1>0), and the next CRC error increment per second ΔC2=C3-C2 is calculated; (3) Fault determination; if any ΔC1 or ΔC2 is greater than 8 times / second, it is recorded as transient interference (no alarm is triggered); if three consecutive CRC error increments per second are all greater than 5 times / second, it is determined to be a physical layer persistent fault. If the link status register and error counter register are both normal, the driver-level local loopback test stage is entered.

[0016] The physical layer state detection process in step S1 includes: (1) Read the link status flag bit in the PHY chip register of the network card; (2) Verify whether the CRC error count exceeds the threshold.

[0017] S2: Perform driver-level local loopback test S 21 Constructing a loopback test data packet The structure of the loopback test data packet is designed as follows: (1) Target MAC address: Set to the MAC address of the embedded device itself (to enable the driver layer to send and receive data automatically); (2) Source MAC address: The embedded device's own MAC address is also used; (3) Load data: Fill in the fixed identifier "0xDEADBEEF" (used for matching verification at the receiving end); (4) Packet length: The minimum legal Ethernet frame length is 64 bytes (to avoid triggering the fragmentation mechanism).

[0018] The above design ensures that data packets only loop back within the network card driver layer and do not pass through the operating system's IP protocol stack, thereby isolating the impact of upper-layer software failures.

[0019] S 22 Inject driver-level local loopback path (1) Pre-register the driver extension module to achieve non-intrusive loading. When the VxWorks system starts, the pre-compiled extension module loop_ext.o is loaded through the system function muxDevLoad(“loop_ext.o”). This extension module adds control logic: when it is detected that the target MAC address of the data packet to be sent is equal to the MAC address of the embedded device itself, the data packet is redirected to the network data receiving queue and the physical sending process is skipped.

[0020] (2) Hardware-level packet filtering and triggering. A filtering circuit (operating independently of the CPU) is inserted between the DMA controller of the network card and the VxWorks system memory. The filtering circuit continuously monitors the data in the transmit buffer. When it detects that the target MAC address is equal to the MAC address of the embedded device and the first 4 bytes of the payload data are equal to "0xDEADBEEF", it immediately sends a preset "dedicated interrupt number" (such as "IRQ 255") to the network card driver. The network card driver notifies the DMA controller to stop the physical transmission of the current data packet and injects the data packet into the network data receive queue.

[0021] In the above design, zero-interruption driver-layer loopback testing of network communication services was achieved for the first time without modifying the business code. Test packets were sent during the service packet sending interval (using network card send queue idle detection). The test packets were injected into the network data receive queue via a DMA bypass channel, avoiding intersection with the service data stream and achieving physical channel isolation.

[0022] S 23 Receive verification and fault diagnosis Start a 500ms timer to wait for the data packet to return. If no data packet is received within the timeout, the network card driver layer or MAC controller is considered to be faulty. If a data packet is received within 500ms (the first 4 bytes of the payload data are equal to "0xDEADBEEF"), the data link layer function of the network card is considered to be normal.

[0023] In the above design, only packets with a specific identifier ("0xDEADBEEF") in their payload are identified to avoid interference from other network data with the diagnostic results.

[0024] S 24 Synergy with physical layer detection The joint decision-making logic with the physical layer is shown in the table below:

[0025] The process of driver-level local loopback testing in step S2 includes: (1) Construct a test data packet with a specific identifier (set the target MAC to be equal to the device's own MAC). (2) Inject the test data packet into the driver layer loopback path; (3) If the driver layer does not receive the loopback packet, it is determined that the network card data link layer is faulty.

[0026] S3: Actively send an ARP request to the gateway and verify the response. S 31 ARP cache reset The VxWorks kernel function arpDelete() is called to clear the ARP cache entries of the target gateway, forcing the embedded device to relearn the gateway's MAC address.

[0027] S 32 Sending directed ARP request frames (2) In the VxWorks system, call the muxDevFind() function to obtain the DMA buffer address (the physical memory area that stores the frames to be sent) and the send descriptor queue (the register group used by the hardware to read the frames) through the network card name (such as "gei0" of the embedded device). (2) Construct the original ARP request frame Constructing an Ethernet frame header includes: Target MAC address: Set to an all-F broadcast address (FF:FF:FF:FF:FF:FF); Source MAC address: The embedded device's own MAC address; Protocol type: 0x0806 (ARP protocol).

[0028] The ARP load is constructed as follows: Hardware type: 0x0001 (Ethernet); Protocol type: 0x800 (IPv4); Hardware address length: 0x06; Protocol address length: 0x04; Operation code: 0x0001 (request); Sender's MAC address: The embedded device's own MAC address; Sender IP: The embedded device's own IP address; Target MAC: FF:FF:FF:FF:FF:FF; Target IP: Gateway address; A frame check sequence is generated using the CRC cyclic redundancy check algorithm as the frame tail.

[0029] (3) Inject directly into the data link layer through the network card driver layer (bypassing the TCP / IP protocol stack) The constructed raw ARP request frame is copied to an empty location in the DMA buffer, the transmit descriptor queue register is activated, and the network card is woken up by writing to the hardware doorbell register to send the ARP request frame.

[0030] S 33 Response detection window (3) Start a 500ms hardware timer (based on the system clock counter); (4) Monitor the network data receiving queue (NIC receiving queue). If an ARP frame with a matching target IP and an opcode of "response" is received within the window period (500ms) (the difference between this and an ARP request frame is the opcode), it is recorded as an ARP response success; if the hardware timer times out (greater than 500ms) and no ARP frame with an opcode of "response" is received, it is recorded as an ARP response timeout (when the physical layer is normal but there is no ARP response), and the next step of switch port mirroring diagnosis and multi-dimensional verification of switch liveness is triggered.

[0031] The ARP verification process in step S3 includes: (1) After clearing the device's ARP cache, send a directed ARP request to the gateway IP; (2) Check whether a response from the gateway MAC address is received within the preset timeout period.

[0032] S4: Switch port mirroring diagnostics, performing multi-dimensional verification of switch liveness. S 41 Switch fingerprint recognition (1) Send an identification query: Use the diagnostic device to send an SNMP GET (query) request to the target switch. The object identifier (OID) queried in this SNMP GET request is the system object ID defined in the international standard, and its OID is "1.3.6.1.2.1.1.2.0". This OID uniquely identifies the model and manufacturer of the switch; (2) Parsing vendor information: After receiving an SNMP GET request, the switch returns its unique System Object ID value. The diagnostic device has a pre-installed vendor database, which matches the returned System Object ID value with the OID prefix in the database; (3) Loading Adaptation Commands: Once the vendor information is identified, the diagnostic device loads the "Port Mirroring Configuration Template" for that vendor from the database. The port mirroring configuration template contains a vendor-specific SNMP OID or CLI (Command Line Interface) command sequence required to configure port mirroring.

[0033] S 42 Automated image session configuration (1) Construct configuration command: The diagnostic device generates an SNMP SET (configuration) request based on the loaded port mirroring configuration template. The core of this SNMP SET request is to set the value of the target OID. This value indicates that the "0 / Value" port of the switch is used as the mirroring target port, that is, the port to which the diagnostic device is connected; (2) Send configuration command: The diagnostic device sends the constructed SNMP SET request to the SNMP agent of the switch; (3) Verify configuration results: The diagnostic device reads the switch's response. If the response status is "success", it indicates that the diagnostic port has been successfully set as the receiver of mirrored traffic; if it fails, other preset backup configuration processes are triggered (such as sending CLI commands via Telnet).

[0034] S 43 Mirror traffic monitoring and verification (1) Connect a packet capture device to the diagnostic port. Set the filter condition to: "Source MAC is the embedded device MAC and the protocol type is ARP"; (2) Continuous monitoring for 10 seconds: If the packet capture device captures an ARP request frame sent by the embedded device, it marks the switch as "traffic reachable". If the packet capture device does not capture the ARP request frame sent by the embedded device, it will mark "Traffic did not reach the switch".

[0035] S 44 : Initiate the switch liveness verification process Once the physical layer test and the driver-level local loopback test both pass (confirming that there is no fault on the device side), the switch liveness verification process is automatically started.

[0036] S 45 Multi-source evidence collection: Employing dual-channel independent acquisition of switch viability evidence to improve anti-interference capabilities. (1) Channel 1: ARP cache entry analysis The VxWorks system directly accesses a specific data structure region in the operating system kernel memory called the ARP cache table. This ARP cache table is automatically maintained by the operating system, and its function is to record the mapping relationships between the IP addresses and MAC addresses of other network devices (including switches) that have recently communicated with this embedded device, as well as the current status and "freshness" of each mapping relationship. In this invention, the VxWorks system precisely locates the starting position of this ARP cache table in memory by querying a predefined internal address.

[0037] The VxWorks system scans the ARP cache table for an entry representing the switch's IP address (typically, this is the device's default gateway address). Once the entry is successfully located, the VxWorks system extracts two key fields for analysis: The "Age" field records the time (in seconds) that has elapsed since the entry was last confirmed. The smaller the value, the newer and more reliable the mapping relationship.

[0038] The "State" field describes the current validity of this mapping. For example, a "REACHABLE" state indicates that the mapping is valid and there has been a recent successful communication confirmation.

[0039] If an entry in the switch's ARP cache table representing the switch's IP address is found to meet both of the following conditions, then strong evidence that the switch is alive is immediately generated: Condition A: The "Age" value is less than or equal to 30 seconds (indicating that the mapping information has not expired); Condition B: The "Status" is "REACHABLE" (indicating that the logical link is working).

[0040] (2) Channel 2: LLDP (Link Layer Discovery Protocol) message monitoring The VxWorks system dynamically attaches a "packet filtering hook" function to the data receive path of the network card driver. This "packet filtering hook" function can filter and capture LLDP protocol packets. Once a valid LLDP protocol packet is captured, the VxWorks system parses it and reads the data type, data length, and data content of the current port status.

[0041] The VxWorks system sets a 2-second listening window for monitoring LLDP protocol packets. If an LLDP protocol packet is successfully captured within 2 seconds and the parsed "Port Status" is "Alive," strong evidence of "switch live" is generated. If no valid LLDP protocol packet is received within the 2-second listening window, it is determined that no liveness evidence has been obtained for this channel.

[0042] The joint decision-making rules for switch status are shown in the table below:

[0043] The port mirroring diagnostic process in step S3 includes: (1) Send port mirroring configuration commands to the switch via the SNMP protocol; (2) Mirror the traffic from the target port to the diagnostic port; (3) Verify on the diagnostic terminal whether an ARP request packet sent by the embedded device has been received.

[0044] The process of multi-dimensional verification of switch liveness includes: (1) Scan the ARP cache for the MAC address liveness status of the switch; (2) Parse LLDP protocol messages to obtain the switch port status; (3) If the switch MAC address is not aged and the LLDP port status is "active", then the switch is considered to be normal.

[0045] S5: Generate a fault location report based on the physical layer status, ARP response results, and switch liveness verification results; The input parameters for the dynamic fault decision tree are defined as follows: (1) Physical layer status (0 indicates abnormality, 1 indicates normality); (2) Drive loop test results (0 indicates abnormality, 1 indicates normal); (3) ARP response result (0 indicates timeout, 1 indicates success); (4) Mirror traffic detection (0 indicates no detection, 1 indicates detection); (5) Switch liveness status (0 indicates not alive, 1 indicates alive).

[0046] The process of making decisions using the fault decision tree includes: (1) If the physical layer is abnormal or the driver-level local loopback test fails, it is determined to be a network card failure; (2) If the physical layer is normal and the ARP response exists, it is determined to be an upper-layer application failure; (3) If the physical layer is normal but the ARP response times out, and the mirrored traffic detects an ARP request frame, then the switch is considered to be faulty; (4) If the physical layer is normal but the ARP response times out and no ARP request frame is detected in the mirrored traffic, it is determined to be a network card driver failure; (5) If the physical layer and driver level local loopback test is normal, but there is no evidence of switch survival, then the switch is determined to be faulty.

[0047] The decision logic table is shown below:

[0048] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for locating network faults in a VxWorks system based on hierarchical diagnosis and cross-validation, characterized in that, Includes the following steps: S1: Detect the physical layer status of the network card of the embedded device in the VxWorks system; S2: Perform driver-level local loopback test; S3: Actively send an ARP request to the gateway and verify the response; S4: Switch port mirroring diagnostics, performing multi-dimensional verification of switch liveness; S5: Generates a fault location report based on the physical layer status, driver-level local loopback test results, ARP response results, and switch liveness verification results.

2. The method as described in claim 1, characterized in that, Step S1 is as follows: S 11 Access the link status register of the PHY chip. (1) Access the address of the link status register of the PHY chip of the network card through the miiTool driver interface provided by the VxWorks system; (2) Read the second bit of the link status register; if the value of this bit is "1", it means that there is a physical link connection between the network card and the switch; if the value of this bit is "0", it means that the physical link is disconnected; S 12 Signal quality diagnosis (1) Read the error counter register of the PHY chip; (2) Perform three consecutive samples and calculate the CRC error increment per second: (a) The first sampled value is denoted as C1; (b) After 1 second, the sampled value is recorded as C2, C2>C1>0, calculate the CRC error increment per second ΔC1 =C2 - C1; (c) After another 1-second interval, the sampled value is recorded as C3, C3>C2>C1>0, and the next CRC error increment per second ΔC2 =C3 -C2 is calculated; (3) Fault determination; if any ΔC1 or ΔC2 is greater than 8 times / second, it is recorded as transient interference; if three consecutive CRC error increments per second are all greater than 5 times / second, it is determined to be a physical layer persistent fault; if the link status register and error counter register are normal, then proceed to the next stage of driver-level local loopback test.

3. The method as described in claim 2, characterized in that, Step S2 is as follows: S 21 Construct a loopback test data packet; The structure of the loopback test data packet is designed as follows: (1) Target MAC address: Set to the MAC address of the embedded device itself; (2) Source MAC address: The embedded device's own MAC address is also used; (3) Load data: Fill in the fixed identifier "0xDEADBEEF"; (4) Packet length: The minimum legal Ethernet frame length is 64 bytes; S 22 Inject driver-level local loopback path (1) Pre-register the driver extension module to achieve non-intrusive loading; among which, when the VxWorks system starts, the pre-compiled extension module loop_ext.o is loaded through the system function muxDevLoad(loop_ext.o). The extension module adds control logic: when the target MAC address of the data packet to be sent is detected to be equal to the MAC address of the embedded device itself, the data packet is redirected to the network data receiving queue and the physical sending process is skipped; (2) Hardware-level packet filtering and triggering: A filtering circuit is inserted between the DMA controller of the network card and the VxWorks system memory. The filtering circuit continuously monitors the data in the transmit buffer. When it detects that the target MAC address is equal to the MAC address of the embedded device and the first 4 bytes of the payload data are equal to 0xDEADBEEF, it sends a preset interrupt number to the network card driver. The network card driver notifies the DMA controller to stop the physical transmission of the current data packet and injects the data packet into the network data receive queue. S 23 Receive verification and fault diagnosis Start a 500ms timer to wait for the data packet to return. If the data packet is not received within the timeout, the network card driver layer or MAC controller is determined to be faulty; if the data packet is received within 500ms, the network card's data link layer function is determined to be normal.

4. The method as described in claim 3, characterized in that, Step S3 is as follows: S 31 ARP cache reset Call the VxWorks kernel function arpDelete() to clear the ARP cache entries of the target gateway, forcing the embedded device to relearn the gateway's MAC address; S 32 Sending directed ARP request frames (1) In the VxWorks system, call the muxDevFind() function to obtain the DMA buffer address and send descriptor queue through the network card name of the embedded device; (2) Construct the original ARP request frame Constructing an Ethernet frame header includes: Target MAC address: Set to an all-F broadcast address (FF:FF:FF:FF:FF:FF); Source MAC address: The embedded device's own MAC address; Protocol type: 0x0806; The ARP load is constructed as follows: Hardware type: 0x0001; Protocol type: 0x800 (IPv4); Hardware address length: 0x06; Protocol address length: 0x04; Operation code: 0x0001; Sender's MAC address: The embedded device's own MAC address; Sender IP: The embedded device's own IP address; Target MAC: FF:FF:FF:FF:FF:FF; Target IP: Gateway address; Frame tail: A frame check sequence generated using the CRC cyclic redundancy check algorithm; (3) Directly inject into the data link layer through the network card driver layer The constructed original ARP request frame is copied to the free location of the DMA buffer, the transmit descriptor queue register is activated, and the network card is woken up by writing to the hardware doorbell register to send the ARP request frame. S 33 Response detection window (1) Start the timer; (2) Monitor the network data receiving queue. If an ARP frame with a matching target IP and an opcode of "response" is received within the window period, it is recorded as an ARP response success. If an ARP frame with an opcode of "response" is not received after the timer expires, it is recorded as an ARP response timeout, and the next step of switch port mirroring diagnosis and multi-dimensional verification of switch survival is triggered.

5. The method as described in claim 4, characterized in that, Step S4 is as follows: S 41 Switch fingerprint recognition (1) Send identification query: Use the diagnostic device to send an SNMP GET request to the target switch. The object identifier OID queried by the SNMP GET request uniquely identifies the model and manufacturer of the switch. (2) Parsing vendor information: After receiving the SNMP GET request, the switch returns its unique system object ID value; the diagnostic device matches the returned system object ID value with the OID prefix in its built-in database; (3) Loading adaptation instructions: Once the vendor information is identified, the diagnostic device loads the port mirroring configuration template for that vendor from the database. The port mirroring configuration template contains the vendor-specific SNMP OID or CLI command sequence required to configure port mirroring. S 42 Automated image session configuration (1) Construct configuration command: The diagnostic device generates an SNMP SET request based on the loaded port mirroring configuration template to set the value of the target OID. The value indicates that the "0 / Value" port of the switch is used as the mirroring target port, that is, the port to which the diagnostic device is connected. (2) Send configuration command: The diagnostic device sends the constructed SNMP SET request to the SNMP agent of the switch; (3) Verify configuration results: The diagnostic device reads the switch's response. If the response status is successful, it indicates that the diagnostic port has been successfully set as the receiver of mirrored traffic; if it fails, other preset backup configuration processes are triggered. S 43 Mirror traffic monitoring and verification (1) Connect a packet capture device to the diagnostic port; set the filter condition to: "The source MAC is the embedded device MAC and the protocol type is ARP"; (2) Continuous monitoring for a certain period of time: If the packet capture device captures an ARP request frame sent by the embedded device, it marks it as "traffic reachable switch"; If the packet capture device does not capture the ARP request frame sent by the embedded device, it will mark "Traffic did not reach the switch"; S 44 : Initiate the switch liveness verification process Once the physical layer detection and driver-level local loopback test both pass, the switch liveness verification process is initiated. S 45 Multi-source evidence collection: Employing dual-channel independent acquisition of switch survival evidence. (1) Channel 1: ARP cache entry analysis The VxWorks system directly accesses a specific data structure area in the operating system kernel memory called the ARP cache table. This ARP cache table is maintained by the operating system and is used to record the mapping relationship between the IP addresses and MAC addresses of other network devices that have recently communicated with this embedded device, as well as the current status of each mapping relationship. The VxWorks system locates the starting position of this ARP cache table in memory by querying a predefined internal address. The VxWorks system scanned the ARP cache table to find the entry representing the switch's IP address. After successfully locating the entry, the VxWorks system extracted two key fields for analysis: The "Age" field records the time elapsed since the entry was last confirmed as valid. The "Status" field describes the current validity of the mapping relationship; If an entry in the switch's ARP cache table representing the switch's IP address is found to meet both of the following conditions, then an evidence of "switch live" is immediately generated: Condition A: If the "age" value is less than or equal to 30 seconds, it indicates that the mapping information has not expired; Condition B: "Status" is "reachable", indicating that the logical link is unobstructed; (2) Channel 2: LLDP protocol message monitoring The VxWorks system dynamically attaches a "packet filtering hook" function to the data receiving path of the network card driver. This "packet filtering hook" function can filter and capture LLDP protocol packets. Once a valid LLDP protocol packet is captured, the VxWorks system parses it and reads the data type, data length and data content of the current port status. The VxWorks system sets up a listening window for the process of listening to LLDP protocol messages. If an LLDP protocol message is successfully captured in the listening window and the parsed "port status" is "alive", then a "switch live" evidence is generated; if no valid LLDP protocol message is received in the listening window, then no liveness evidence is obtained.

6. The method as described in claim 5, characterized in that, The input parameters for the dynamic fault decision tree in step S5 are defined as follows: (1) Physical layer status, 0 indicates abnormality, 1 indicates normality; (2) Driver-level local loopback test results, 0 indicates abnormality, 1 indicates normality; (3) ARP response result, 0 indicates timeout, 1 indicates success; (4) Mirror traffic detection, 0 indicates no detection, 1 indicates detection; (5) Switch liveness status: 0 indicates not alive, 1 indicates alive.

7. The method as described in claim 5, characterized in that, The process of making a decision using the fault decision tree in step S5 includes: (1) If the physical layer is abnormal or the driver-level local loopback test fails, it is determined to be a network card failure; (2) If the physical layer is normal and the ARP response exists, it is determined to be an upper-layer application failure; (3) If the physical layer is normal but the ARP response times out, and the mirrored traffic detects an ARP request frame, then the switch is considered to be faulty; (4) If the physical layer is normal but the ARP response times out and no ARP request frame is detected in the mirrored traffic, it is determined to be a network card driver failure; (5) If the local loopback test of the physical layer and driver level is normal, but there is no evidence of the switch being alive, then the switch is determined to be faulty.

8. A system for implementing the method as described in any one of claims 1 to 7.

9. An embedded network fault diagnosis method based on the method described in any one of claims 1 to 7.

10. An embedded network fault diagnosis system based on the system described in claim 8.

Images