Two-layer network bridge equipment management system and method based on ICMP protocol
By building an independent management plane in the Layer 2 network bridging device and embedding an IP layer bypass interception mechanism, ICMP Echo Request messages are identified and processed, solving the problem of remote diagnosis and recovery when the device fails, and achieving efficient operation and maintenance.
Patent Information
- Application Number
- CN202511960974.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-24
- Publication Date
- 2026-03-17
AI Technical Summary
In existing technologies, when Layer 2 network bridging devices experience MAC address table corruption, port congestion, or network loops, management messages cannot be forwarded normally, causing the device to fall into a fault state. Maintenance personnel cannot remotely diagnose and restore the device, increasing network fault recovery time and maintenance costs.
An independent management plane is constructed that is decoupled from the Layer 2 forwarding plane logic. By embedding a bypass interception mechanism in the IP layer of the network protocol stack, ICMP Echo Request messages are identified and extracted, directly imported into the management plane, and response messages are sent through a high-priority sending queue, bypassing the conventional bridging logic.
Even when the bridging function is disabled, remote command and message sending can still be achieved, reducing network failure recovery time and maintenance costs.
Smart Images
Figure CN121690948A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer networks, and in particular to a second-layer bridge device management system and method based on ICMP protocol. BACKGROUND
[0002] The second-layer network bridge device works in the second layer (data link layer) of the OSI model, and its core function is to forward data frames according to MAC addresses.
[0003] The management message of the prior art needs to rely on the normal bridge logic of the device for forwarding and processing. Once the device has a MAC address table disorder, port blocking, or network loop, etc. second-layer forwarding plane failure, the management message cannot reach the control core of the device or be correctly processed, resulting in the device falling into a failure state in the case of intact hardware, and the operation and maintenance personnel cannot diagnose and recover through remote means, and are seriously dependent on on-site physical intervention, which seriously increases the recovery time of network failure and operation and maintenance cost.
[0004] The present application constructs an independent management plane that is decoupled from the second-layer forwarding plane logic and runs in parallel, implants a bypass interception mechanism at the IP layer of the network protocol stack, all incoming IP packets are monitored and filtered in real time before being submitted to the upper protocol stack or forwarding engine, when a specific ICMP Echo Request message carrying a management instruction is identified, the message is directly imported into an independent management processing pipeline, and the sending path of the management response is also designed as an independent channel, the response message does not pass through the normal bridge query and forwarding logic, but is directly delivered to the network driver for sending through a high-priority IP layer sending queue, ensuring that the entire data path from the reception of the management request to the final response is isolated from the business data forwarding path that may fail, so that the operation and maintenance personnel can still send remote commands and information in the case of complete bridge function failure. SUMMARY
[0005] In order to overcome the problem that the management message of the prior art needs to rely on the normal bridge logic of the device for forwarding and processing, once the device has a MAC address table disorder, port blocking, or network loop, etc. second-layer forwarding plane failure, the management message cannot reach the control core of the device or be correctly processed, resulting in the device falling into a failure state in the case of intact hardware, and the operation and maintenance personnel cannot diagnose and recover through remote means, and are seriously dependent on on-site physical intervention, which seriously increases the recovery time of network failure and operation and maintenance cost.
[0006] The technical solution of the present application is: a second-layer bridge device management system based on ICMP protocol, comprising the following modules: ICMP packet interception and preprocessing module: used for bypassing the incoming packet at the IP layer of the network protocol stack, quickly identifying and extracting ICMP management packets, and sending them to the management plane; Instruction analysis and security control module: used for decoding instructions, extracting data, and security verification of legal ICMP Echo Request packets; Lightweight instruction execution and state collection module: according to the parsed instructions, call the underlying system interface to execute the corresponding operation, and collect device state data, stateless, event-driven; Response packaging and priority sending module: the execution result is packaged as an ICMP Echo Reply packet, which is directly returned through a high-priority sending queue, bypassing the regular routing and bridging logic.
[0007] As a preferred embodiment, the ICMP packet interception and preprocessing module comprises: A11: Packet monitoring unit, including network interface controller driver interface, IP packet buffer and protocol number extractor, used for real-time monitoring of all incoming IP packets and extracting IP header protocol number; A12: Protocol filtering unit, including ICMP protocol identifier, filtering rule storage and discard queue manager, used for filtering packets with protocol number 1 and discarding non-ICMP traffic; A13: Type identification unit, including ICMP header parser, type / code matcher and temporary packet buffer area, used for identifying ICMP packet type and only passing Echo Request.
[0008] As a preferred embodiment, the instruction analysis and security control module comprises: A21: Instruction decoding unit, including instruction mapping table storage, field extractor and operation code conversion logic, used for parsing Identifier and Sequence Number and mapping them to specific operation instructions; A22: Data extraction unit, including TLV parsing engine, data buffer and format verifier, used for extracting TLV format data in the Data field and converting it to internal data structure; A23: Security verification unit, including IP white list storage, message authentication code verifier and permission mapping table, used for source IP white list verification, packet signature verification, and permission hierarchical control.
[0009] As a preferred embodiment, the lightweight instruction execution and state collection module comprises: A31: Instruction execution unit, including system call interface library, instruction execution queue and execution state feedback, used for directly calling operating system / firmware API to execute query, configuration, and control instructions; A32: State acquisition unit, including state sensor interface, data acquisition scheduler and real-time data buffer, used for collecting bridge state, port count or system resource real-time data; A33: Result assembly unit, including data serializer, response format template and result checksum generator, used for serializing execution result or state data into response format.
[0010] As preferred, the response packaging and priority sending module includes: A41: Response packaging unit, including ICMP packet constructor, checksum calculator and packet length controller, used for packaging data into ICMP Echo Reply format and filling in checksum; A42: Priority scheduling unit, including priority queue manager, sending scheduler and queue state monitor, used for sending management response packet into high priority sending queue; A43: Network driver interface unit, including driver sending interface, sending buffer and sending confirmation processor, used for sending packet directly to network driver sending without going through layer 2 forwarding.
[0011] A method for managing layer 2 bridge equipment based on ICMP protocol, comprising the following steps: S11: Real-time listening, screening and extracting ICMP request packet as management instruction at device IP layer; S12: Decoding, security verification and authority control of the extracted ICMP packet; S13: According to the analysis result, calling system interface to execute corresponding operation and collecting device state, and assembling the result into structured response data; S14: Packaging the response data into ICMP reply packet, directly returning through independent high priority sending channel, bypassing layer 2 forwarding logic.
[0012] As preferred, when receiving, identifying and preliminarily processing the packet, the following steps are included: S21: Physical network card driver program receives Ethernet frame from link layer, performs CRC check and frame length check, sends valid data frame into buffer, and notifies protocol stack for subsequent processing; S22: The driver program strips the Ethernet frame header and extracts the protocol type field therein. If it is IPv4 or IPv6, the IP packet is submitted to the network layer input queue; S23: The IP layer processing function analyzes the header of the IP packet, extracts the "protocol number" field, judges whether it is ICMP protocol, and records the source IP address and target IP address; S24: Set up an intercept hook function in the IP layer receiving path, capture the data packet with protocol number 1, and copy it to a dedicated buffer for the management plane; S25: Analyze the type and code fields in the ICMP message header, and only keep the message with type 8 and code 0, and discard the rest or hand them over to the system for default processing; S26: Store the identified ICMP Echo Request message in the temporary cache queue of the management plane, and start the timeout timer; S27: Send an interrupt or event signal to the instruction analysis and security control module of the management plane, notifying it of the arrival of a new management message, and preparing to enter the next stage of processing.
[0013] As a preferred, during instruction analysis, security verification and permission control, the following steps are included: S31: Read the identifier, sequence number and data field from the ICMP Echo Request message and store them in the analysis buffer; S32: According to the high 4 bits and low 12 bits of the Identifier field, map the binary code to the corresponding operation command; S33: If the Data field uses TLV format, read the type, length and value three parts in turn, and convert them into an internal recognizable configuration parameter structure; S34: Compare the source IP address of the message with the list of trusted administrator IP addresses pre-configured by the device, and if it is not in the list, discard the message and record the security log; S35: Extract the message authentication code from the specified position of the Data field, recalculate the MAC value of the message content using the pre-shared key, and compare them; S36: According to the operation permission level corresponding to the Identifier, check whether the current request exceeds its permission range, and refuse to execute if it exceeds the authority; S37: Check whether the Sequence Number is within the valid time window, and compare it with the recently processed sequence number to prevent the same instruction from being executed repeatedly.
[0014] As a preferred, during instruction execution, state collection and result assembly, the following steps are included: S41: If the instruction is a state query (such as 0x5351), call kernel functions such as get_bridge_status(), get_port_statistics(), etc. to obtain real-time data such as MAC table entries, port traffic, CPU usage, etc. S42: If the instruction is configuration issuing (such as 0x4346), new parameters in the Data field are parsed, functions such as set_port_state(), update_mac_aging_time() are called, and the original configuration is backed up to the non-volatile memory; S43: If the instruction is device control (such as restart 0x4D47), after security verification, the function system_reboot() or reset_bridge_module() is called, and operation logs are recorded; S44: Hardware state information of temperature sensors, power supply voltage and fan speed is read through I2C, SPI or GPIO interfaces, and is formatted into a unified data structure; S45: Collected state data or execution results are serialized according to a predefined binary format or TLV structure, data length is calculated, and a check code is generated; S46: The serialized data, execution result code and timestamp are combined into a response data block, and are prepared for encapsulation into an ICMP reply message; S47: The assembled response data is stored in a sending buffer area, and a response encapsulation module is notified for next step processing.
[0015] As preferred, the following steps are included when responding to encapsulation, priority scheduling and network sending: S51: The ICMP type is set to 0 (Echo Reply), the code is set to 0, the checksum is calculated, and the Identifier and Sequence Number fields in the request message are multiplexed; S52: The response data block assembled in the third step is written into the Data field of the ICMP message, and the total length of the ICMP message is updated according to the data length; S53: A new checksum is calculated based on the complete ICMP message content, and is written into the checksum field of the message header; S54: The ICMP message is encapsulated into an IP packet, the target IP address is set to the source IP address of the request message, the source IP address is set to the device management interface IP, and the protocol number is set to 1; S55: The encapsulated IP packet is sent to a high-priority sending queue specially set for the management plane, which is independent of the forwarding queue of ordinary service data; S56: In the sending process, the MAC address table is not queried, bridge forwarding decisions are not executed, and a network driver sending interface is directly called to submit the packet to the physical network card sending buffer area; S57: The network driver program sends the data frame to the physical link, and records the management interaction log of this time, including time, operation type and response state, after successful sending.
[0016] Advantages of the present application: The management packet of the prior art needs to rely on the normal bridging logic of the device for forwarding and processing. Once the MAC address table of the device is disordered, the port is blocked, or the network loop and other two-layer forwarding plane faults occur, the management packet cannot reach the control core of the device or be correctly processed, so that the device falls into a fault state in the case of perfect hardware, the operation and maintenance personnel cannot diagnose and recover through remote means, and physical intervention is seriously relied on, which seriously increases the recovery time of network faults and the operation and maintenance cost. The present scheme constructs an independent management plane which is decoupled from the two-layer forwarding plane logic and runs in parallel, implants a bypass interception mechanism in the IP layer of the network protocol stack, all the incoming IP data packets are monitored and screened in real time before being submitted to the upper protocol stack or the forwarding engine, when the specific ICMP Echo Request packet carrying the management instruction is identified, the packet is directly introduced into the independent management processing pipeline, and the sending path of the management response is also designed as an independent channel. The response packet does not pass through the normal bridging query and forwarding logic, but is directly delivered to the network driver for sending through a high-priority IP layer sending queue, so as to ensure that the entire data path from the reception of the management request to the final response is isolated from the possible fault business data forwarding path, so that the operation and maintenance personnel can still send remote commands and information in the case of complete bridging function failure. BRIEF DESCRIPTION OF DRAWINGS
[0017] Figure 1 A two-layer bridge device management system framework based on an ICMP protocol is shown. Figure 2 A two-layer bridge device management method framework flowchart based on an ICMP protocol is shown. Figure 3 A two-layer bridge device management method packet reception, identification and preliminary processing flowchart based on an ICMP protocol is shown. Figure 4 A two-layer bridge device management method instruction analysis, security verification and permission control flowchart based on an ICMP protocol is shown. DETAILED DESCRIPTION
[0018] The present application will be further described below in conjunction with the drawings and examples.
[0019] Please refer to Figure 1 The present application provides an embodiment: a two-layer bridge device management system based on an ICMP protocol, which comprises the following modules: ICMP packet interception and preprocessing module: used for bypassing the incoming packets at the IP layer of the network protocol stack, quickly identifying and extracting ICMP management packets, and sending them to the management plane; Instruction analysis and security control module: used for decoding instructions, extracting data, and security verification of legal ICMP Echo Request packets; Lightweight instruction execution and state collection module: according to the parsed instructions, call the underlying system interface to execute the corresponding operation, and collect device state data, stateless, event-driven; Response packaging and priority sending module: the execution result is packaged as an ICMP Echo Reply packet, which is directly returned through a high-priority sending queue, bypassing the regular routing and bridging logic.
[0020] As a preferred embodiment, the ICMP packet interception and preprocessing module comprises: A11: Packet monitoring unit, including network interface controller driver interface, IP packet buffer and protocol number extractor, used for real-time monitoring of all incoming IP packets and extracting IP header protocol number; A12: Protocol filtering unit, including ICMP protocol identifier, filtering rule storage and discard queue manager, used for filtering packets with protocol number 1 and discarding non-ICMP traffic; A13: Type identification unit, including ICMP header parser, type / code matcher and temporary packet buffer area, used for identifying ICMP packet type and only passing Echo Request.
[0021] As a preferred embodiment, the instruction analysis and security control module comprises: A21: Instruction decoding unit, including instruction mapping table storage, field extractor and operation code conversion logic, used for parsing Identifier and Sequence Number and mapping them to specific operation instructions; A22: Data extraction unit, including TLV parsing engine, data buffer and format verifier, used for extracting TLV format data in the Data field and converting it to internal data structure; A23: Security verification unit, including IP white list storage, message authentication code verifier and permission mapping table, used for source IP white list verification, packet signature verification, and permission hierarchical control.
[0022] As a preferred embodiment, the lightweight instruction execution and state collection module comprises: A31: Instruction execution unit, including system call interface library, instruction execution queue and execution state feedback, used for directly calling operating system / firmware API to execute query, configuration, and control instructions; A32: State collection unit, including state sensor interface, data collection scheduler and real-time data buffer, for collecting bridge state, port count or system resource real-time data; A33: Result assembly unit, including data serializer, response format template and result checksum generator, for serializing execution result or state data into response format.
[0023] As preferred, the response packaging and priority sending module includes: A41: Response packaging unit, including ICMP packet constructor, checksum calculator and packet length controller, for packaging data into ICMP Echo Reply format and filling in checksum; A42: Priority scheduling unit, including priority queue manager, sending scheduler and queue state monitor, for sending management response packets into high-priority sending queue; A43: Network driver interface unit, including driver sending interface, sending buffer and sending acknowledgement processor, for sending packets directly to network driver sending without going through layer 2 forwarding.
[0024] Please refer to Figures 2-4 In this embodiment, a layer 2 bridge device management method based on ICMP protocol includes the following steps: S11: Real-time listening, filtering and extracting ICMP request packets as management instructions at device IP layer; S12: Decoding instructions, security verification and authority control on the extracted ICMP packets; S13: According to the analysis result, calling system interface to execute corresponding operations and collecting device state, and assembling results into structured response data; S14: Packaging response data into ICMP reply packets, directly returning through independent high-priority sending channel, bypassing layer 2 forwarding logic.
[0025] As preferred, when receiving, identifying and initially processing packets, the following steps are included: S21: Physical network card driver program receives Ethernet frame from link layer, performs CRC check and frame length check, sends valid data frame into buffer, and notifies protocol stack for subsequent processing; S22: Driver program strips Ethernet frame header, extracts protocol type field therein, and if it is IPv4 or IPv6, submits IP packet to network layer input queue; S23: IP layer processing function analyzes the header of IP packet, extracts "protocol number" field, judges whether it is ICMP protocol, and records source IP address and target IP address; S24: Set up an intercept hook function in the IP layer receiving path, capture the data packet with protocol number 1, and copy it to a dedicated buffer for the management plane; S25: Analyze the type and code fields in the ICMP message header, and only keep the message with type 8 and code 0, and discard the rest or hand them over to the system for default processing; S26: Store the identified ICMP Echo Request message in the temporary cache queue of the management plane, and start the timeout timer; S27: Send an interrupt or event signal to the instruction analysis and security control module of the management plane, notifying it of the arrival of a new management message, and preparing to enter the next stage of processing.
[0026] As preferred, during instruction analysis, security verification and permission control, the following steps are included: S31: Read the identifier, sequence number and data field from the ICMP Echo Request message and store them in the analysis buffer; S32: According to the high 4 bits and low 12 bits of the Identifier field, map the binary code to the corresponding operation command; S33: If the Data field uses the TLV format, read the type, length and value three parts in turn, and convert them into an internal recognizable configuration parameter structure; S34: Compare the source IP address of the message with the list of trusted administrator IP addresses pre-configured by the device, and if it is not in the list, discard the message and record the security log; S35: Extract the message authentication code from the specified position of the Data field, recalculate the MAC value of the message content using the pre-shared key, and compare them; S36: According to the operation permission level corresponding to the Identifier, check whether the current request exceeds its permission range, and refuse to execute if it exceeds the permission; S37: Check whether the Sequence Number is within the valid time window, and compare it with the recently processed sequence number to prevent the same instruction from being repeatedly executed.
[0027] As preferred, during instruction execution, state collection and result assembly, the following steps are included: S41: If the instruction is a state query (such as 0x5351), call kernel functions such as get_bridge_status(), get_port_statistics(), etc. to obtain real-time data such as MAC table entries, port traffic, CPU usage, etc. S42: If the instruction is configuration issuing (such as 0x4346), parse the new parameters in the Data field, call functions such as set_port_state(), update_mac_aging_time(), etc., and backup the original configuration to the non-volatile memory; S43: If the instruction is device control (such as reboot 0x4D47), after the security verification is passed, call functions such as system_reboot() or reset_bridge_module(), and record the operation log; S44: Read the hardware state information of the temperature sensor, power voltage and fan speed through the I2C, SPI or GPIO interface, and format it into a unified data structure; S45: Serialize the collected state data or execution result according to the pre-defined binary format or TLV structure, calculate the data length and generate the check code; S46: Merge the serialized data, execution result code and timestamp into a response data block, and prepare to package it into an ICMP reply message; S47: Store the assembled response data into the sending buffer area, and notify the response packaging module for the next step of processing.
[0028] As preferred, when responding to the package, priority scheduling and network sending, the following steps are included: S51: Set the ICMP type to 0 (Echo Reply), code to 0, calculate the checksum, and multiplex the Identifier and Sequence Number fields in the request message; S52: Write the response data block assembled in the third step into the Data field of the ICMP message, and update the total length of the ICMP message according to the data length; S53: Calculate the new checksum based on the complete ICMP message content, and write it into the checksum field of the message header; S54: Package the ICMP message into an IP packet, set the target IP address to the source IP address of the request message, set the source IP address to the device management interface IP, and set the protocol number to 1; S55: Send the packaged IP packet to the high-priority sending queue specially set for the management plane, which is independent of the forwarding queue of ordinary service data; S56: Do not query the MAC address table and do not perform bridge forwarding decision during the sending process, directly call the network driver sending interface, and submit the packet to the physical network card sending buffer area; S57: The network driver program sends the data frame to the physical link, records the management interaction log of this time, including time, operation type and response status, after the sending is successful.
[0029] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.
Claims
1. A system for managing a layer 2 bridge device based on ICMP protocol; characterized in that: Comprise the following module components: ICMP message interception and preprocessing module: for bypassing the IP layer of the network protocol stack to listen to the incoming message, quickly identify and extract ICMP management messages, and send them to the management plane; Instruction analysis and security control module: for decoding, data extraction and security verification of legal ICMP Echo Request messages; Lightweight instruction execution and state collection module: according to the parsed instructions, call the underlying system interface to execute the corresponding operation, and collect device state data, stateless, event-driven; Response packaging and priority sending module: the execution result is packaged as an ICMP Echo Reply message, which is directly returned through a high-priority sending queue, bypassing the regular routing and bridging logic.
2. The system according to claim 1, wherein the system is based on ICMP protocol. The ICMP message interception and preprocessing module comprises: A11: message listening unit, comprising network interface controller driver interface, IP message buffer and protocol number extractor, for real-time listening to all incoming IP packets and extracting IP header protocol number; A12: protocol filtering unit, comprising ICMP protocol identifier, filtering rule storage and discard queue manager, for filtering messages with protocol number 1 and discarding non-ICMP traffic; A13: type identification unit, comprising ICMP header parser, type / code matcher and temporary message buffer area, for identifying ICMP message type and only passing Echo Request.
3. The system according to claim 2, wherein the system is further configured to: receive an ICMP echo request from the second device; and send an ICMP echo reply to the second device. The instruction analysis and security control module comprises: A21: instruction decoding unit, comprising instruction mapping table storage, field extractor and operation code conversion logic, for parsing Identifier and Sequence Number and mapping to specific operation instructions; A22: data extraction unit, comprising TLV parsing engine, data buffer and format verifier, for extracting TLV format data in the Data field and converting it into an internal data structure; A23: security verification unit, comprising IP white list storage, message authentication code verifier and permission mapping table, for source IP white list verification, message signature verification and permission hierarchical control.
4. The system according to claim 1, wherein the system is further characterized by: The lightweight instruction execution and state collection module comprises: A31: instruction execution unit, comprising system call interface library, instruction execution queue and execution state feedback, for directly calling operating system / firmware API to execute query, configuration and control instructions; A32: state collection unit, comprising state sensor interface, data collection scheduler and real-time data buffer, for collecting bridge state, port count or system resource real-time data; A33: result assembly unit, comprising data serializer, response format template and result checksum generator, for serializing execution results or state data into response format.
5. The system according to claim 1, wherein the system is further characterized by: The response packaging and priority sending module comprises: A41: response packaging unit, comprising ICMP message constructor, checksum calculator and message length controller, for packaging data into ICMP Echo Reply format and filling in checksum; A42: a priority scheduling unit, including a priority queue manager, a sending scheduler and a queue state monitor, for sending the management response message into a high priority sending queue; A43: a network driver interface unit, including a driver sending interface, a sending buffer and a sending confirmation processor, for sending the message directly to the network driver sending without going through the layer 2 forwarding.
6. The system according to any one of claims 1-5, wherein the system is based on ICMP protocol. An ICMP protocol-based layer 2 bridge device management method, comprising the following steps: S11: Real-time monitoring, screening and extracting ICMP request messages as management instructions at the device IP layer; S12: Decoding, security verification and authority control of the extracted ICMP messages; S13: According to the analysis result, calling the system interface to execute the corresponding operation and collecting the device state, and assembling the result into structured response data; S14: Encapsulating the response data into an ICMP reply message, directly returning through an independent high priority sending channel, bypassing the layer 2 forwarding logic.
7. The system and method for ICMP protocol based management of a Layer 2 bridge device according to claim 6, wherein: When receiving, identifying and preliminarily processing the message, the following steps are included: S21: The physical network card driver program receives the Ethernet frame from the link layer, performs CRC check and frame length check, sends the valid data frame to the buffer, and notifies the protocol stack for subsequent processing; S22: The driver program strips the Ethernet frame header and extracts the protocol type field, and if it is IPv4 or IPv6, submits the IP packet to the network layer input queue; S23: The IP layer processing function analyzes the header of the IP packet, extracts the "protocol number" field, judges whether it is the ICMP protocol, and records the source IP address and target IP address; S24: Setting an interception hook function in the IP layer receiving path, capturing the data packet with protocol number 1, and copying a copy to the management plane dedicated buffer; S25: Analyzing the type and code fields in the ICMP message header, only keeping the messages with type 8 and code 0, and discarding or handing over the rest to the system default processing; S26: Storing the identified ICMP Echo Request message into the temporary cache queue of the management plane, and starting the timeout timer; S27: Sending an interrupt or event signal to the instruction analysis and security control module of the management plane, notifying it that a new management message has arrived, and preparing to enter the next stage of processing.
8. The system and method for managing a Layer 2 bridge device based on ICMP protocol according to claim 6, wherein: When analyzing the instruction, security verification and authority control, the following steps are included: S31: Reading the identifier, sequence number and data field from the ICMP Echo Request message and storing them in the analysis buffer; S32: According to the high 4 bits and low 12 bits of the Identifier field, mapping the binary code to the corresponding operation command; S33: If the Data field uses TLV format, read the type, length and value three parts in turn, and convert them into internal recognizable configuration parameter structure; S34: Comparing the source IP address of the message with the trusted administrator IP list pre-configured by the device, if not in the list, discarding the message and recording the security log; S35: Extract the message authentication code from the specified location of the Data field, recalculate the MAC value using the pre-shared key for the message content, and compare them; S36: Check whether the current request exceeds its authority range according to the operation authority level corresponding to the Identifier, and refuse execution if it exceeds the authority; S37: Check whether the Sequence Number is within the valid time window, and compare it with the latest processed sequence number to prevent the same instruction from being repeatedly executed.
9. The system and method for ICMP protocol based management of a Layer 2 bridge device according to claim 6, wherein: When performing instruction execution, state collection, and result assembly, the following steps are included: S41: If the instruction is a state query (such as 0x5351), call the get_bridge_status(), get_port_statistics(), and other kernel functions to obtain real-time data such as MAC table entries, port traffic, CPU usage, etc. S42: If the instruction is a configuration delivery (such as 0x4346), parse the new parameters in the Data field, call functions such as set_port_state(), update_mac_aging_time(), etc., and backup the original configuration to non-volatile memory; S43: If the instruction is a device control (such as reboot 0x4D47), after security verification, call the system_reboot() or reset_bridge_module() function, and record the operation log; S44: Read the hardware state information of temperature sensors, power supply voltage, and fan speed through I2C, SPI, or GPIO interfaces, and format them into a unified data structure; S45: Serialize the collected state data or execution results in the pre-defined binary format or TLV structure, calculate the data length, and generate a check code; S46: Merge the serialized data, execution result code, and timestamp into a response data block, and prepare to package it as an ICMP reply message; S47: Store the assembled response data into the sending buffer area, and notify the response packaging module for further processing.
10. The system and method for managing a Layer 2 bridge device based on ICMP protocol according to claim 6, wherein: When performing response packaging, priority scheduling, and network sending, the following steps are included: S51: Set the ICMP type to 0 (Echo Reply) and the code to 0, calculate the checksum, and reuse the Identifier and Sequence Number fields in the request message; S52: Write the response data block assembled in the third step into the Data field of the ICMP message, and update the total length of the ICMP message according to the data length; S53: Calculate the new checksum based on the complete ICMP message content, and write it into the checksum field of the message header; S54: Package the ICMP message into an IP packet, set the destination IP address to the source IP address of the request message, the source IP address to the device management interface IP, and the protocol number to 1; S55: Send the packaged IP packet to the high-priority sending queue specially set for the management plane, which is independent of the forwarding queue for ordinary service data; S56: In the sending process, the MAC address table is not queried, the bridge forwarding decision is not executed, the network driver sending interface is directly called, and the data packet is submitted to the physical network card sending buffer; S57: The network driver program sends the data frame to the physical link, and records the management interaction log of this time, including time, operation type and response state after successful sending.