Marsio (marsio4/marsio5)

An internal TSG operations/troubleshooting manual lays out TSG's full traffic pipeline (NIC -> mrzcpd/marsio capture driver -> sapp DPI engine -> firewall/proxy(KNI->TFE)/active-defense/WAN-NAT policy branches) and shows engineers using maat_redis_tool to pull the live Redis-synced blocking policy tables (TSG_SECURITY_COMPILE, TSG_OBJ_IP_ADDR, TSG_OBJ_APP_ID) and filter them by numeric policy/object ID to debug why a block rule isn't firing.

Crash-dump stack traces reveal TSG's core packet-processing engine (sapp) architecture: a custom multi-threaded C engine using 'marsio' as the DPDK-style packet-I/O driver, a plugin system for protocol handlers (confirmed: plug/protocol/http/http.so), and a libdocumentanalyze component that actively decompresses gzip content and parses ZIP/document formats found inside HTTP bodies -- i.e. inspection goes beyond headers into reconstructed application content.

An internal "DPI Benchmark" methodology document names the three production components underlying TSG's DPI stack and proposes benchmarking each against open-source equivalents: Marsio (DPDK-based packet I/O) for receive/transmit, Sapp ("网络安全开发平台", a high-speed traffic-processing platform) for protocol parsing and flow-table management, and Maat (Hyperscan-class signature engine with Redis-based multi-machine config sync) for pattern scanning.

An internal porting/test report documents migrating sapp and marsio (its DPDK-based packet-I/O layer) onto domestic Huawei Kunpeng ARM64 hardware (华鲲振宇 TG225 B1, dual KP920-5250 CPUs, 1TB RAM) running the Kylin (麒麟) domestic Linux distribution, using Huawei's Devkit source-migration scanning tool and DPDK 20.11.3 with hugepage/vfio-pci NIC binding, functionally validated via tcpreplay packet-injection tests.

MESA Lab's internal "tcp_burst" traffic-replay tool (common_tools/tcp_burst, a fork of tcpreplay) bundles fragroute — a well-known IDS/DPI-evasion toolkit implementing TCP/IP fragmentation, segment reordering, chaffing, duplication, and delay — and integrates its replay path with the marsio packet-I/O framework also used by sapp, indicating fragroute-style evasion techniques are used internally to test TSG/sapp's DPI robustness against fragmentation- and reordering-based evasion.

A repo named "active-defense/houyi-deploy" is an Ansible playbook that installs a component called "houyi" (后羿) alongside sapp and a "wire-graft" packet-injection module (matching the taxonomy's marsio "wired_graft" plugin); the bundled RPMs/scripts include standalone binaries named tcp_syn_flood, udp_dns_flood, and a DNS-reflection-amplification script (reflect_dns.sh), indicating this TSG-adjacent platform includes offensive flooding/DDoS capability, not just passive blocking.

TSG ships a built-in offensive "active defense" (主动防御) module named houyi (后羿), built on the sapp/marsio/mrzcpd stack, that performs spoofed-source-IP network-layer flood attacks, DNS/NTP/Memcached reflection-amplification attacks, and application-layer (HTTP/HTTPS) CC floods against a configured target. Spoofed source IPs are drawn from named CIDR-range "profiles" (e.g. 10.1.1.0/24), and policy is distributed via Redis and issued either through an interface called "安天" (Antiy) or by directly calling a "毕方" (Bifang) API. Deployment is via Ansible from git.mesalab.cn/tsg/houyi-deploy, packaged as RPMs installed under /opt/houyi and as sapp plugins under /home/mesasoft/sapp_run/plug.

A Rust rewrite of Geedge's plugin/session-management framework, internally named "Stellar," binds to libmarsio for packet I/O and implements its own TCP reassembly and protocol decoders (Ethernet/IP/TCP/UDP/DNS/HTTP); a sibling repo's build artifacts show it ships as RPM "stellar-on-sapp", indicating it is a next-generation session/event layer sitting on top of the sapp DPI engine. "Stellar" is not yet a named product in the taxonomy.

The IPReuse/mrl tool -- a NAT link-learning daemon integrated with Marsio (which fills VXLAN headers using MRL-supplied virtual link IDs) and MAAT (shared 'maat_feather' candidate/nominee tables) -- ships a Kazakhstan-specific MaxMind-format IP geolocation database (Kazakhstan_v4.mmdb) directly in its own config directory and again inside its bundled IPLocator dependency. Commit history describes self-learning of link info, SNAT/DNAT policy support, and sending virtual link IDs to 'the platform' for Marsio's VXLAN encapsulation.

An mrzcpd installer script registers a full set of AMD-Zen-optimized ("znver1") binaries and systemd units via update-alternatives — mrzcpd, mrtools-pinfo, mrpdump, monit_stream, monit_device, monit_obp, mrmarch, dpdk-hugepages.py, dpdk-devbind.py, plus services mrapm_device/mrapm_stream/mrapm_obp/mrtunnat/mrzcpd_hugepages_setup/mrzcpd_hwdb_setup — confirming mrzcpd's packet-capture/injection layer is built directly on DPDK with hugepage-backed, CPU-microarchitecture-tuned packet I/O, consistent with the taxonomy's marsio DPDK-framework note.

TSG's data plane runs as containers (firewall, packet-io-engine, proxy, sce, shaping) per TSGX appliance, built on an internal packet framework called Marsio/MRZCPD (config at /opt/tsg/mrzcpd/etc/mrglobal.conf), deployed with 32GB hugepages and tunable TX rate-limiting per bonded NIC.

An official "Geedge Networks Confidential And Proprietary" sapp/mrzcpd operations manual documents the packet-injection API (MESA_kill_tcp / MESA_inject_pkt) used for both out-of-band mirror-tap RST injection (relies on the local box's own IP routing table to send) and inline in-path injection (requires mrtunnat.conf tunnel-tracking state -- use_recent_tunnel, use_link_info_table -- keyed on outer/inner MAC and link_id/link_dir), plus the Marsio DPDK-based driver's I/O sub-modes (marsio4, marsio_vxlan, pag_marsio, agent_smith) and its role extracting VXLAN/GTP encapsulation metadata and stamping link/circuit identifiers into mirrored packets' MAC field for session-log correlation.

A burst of UDP traffic at a Xinjiang site (Bole-IGW -- Bole is a Xinjiang city, matching gfw.report's identification of Xinjiang as a domestic TSG deployment region) hitting monitor policies drove all packet-processing-core CPU to >99%, exhausting DPDK mbuf buffers and triggering cascading container restarts across ~10 NPB (Network Packet Broker) devices.

TSG's traffic pipeline has an encapsulation-handling layer called "marsio" (versions marsio4/marsio5) sitting in front of "sapp" (the core stream-processing engine). For unencapsulated mirrored traffic, a "wired_graft" plugin injects link/circuit identifiers into the MAC address field of copied packets so downstream session logging can recover which physical link a flow came from; for encapsulated traffic (e.g. VXLAN) marsio itself must expose that metadata.

A crash backtrace from an Ethiopia-site TSG-OS node reveals internal DPI plugin architecture: a core 'sapp' binary (/opt/tsg/sapp/sapp) loads protocol-dissector plugins (dtls, tsg_master.so) chained through a 'marsio4' packet-processing worker, with a KNI/DPDK-style packet path (eth_entry -> ipv4_entry -> vxlan_entry -> gtp_entry -> dtls dissector). The specific bug was an uninitialized DTLS hello-verify cookie field.

Reveals internal architecture of TSG's traffic classification engine: the 'sapp' process (binary at /opt/tsg/sapp/sapp, version sapp-4.2.90) uses a packet-I/O layer called 'marsio', a custom app-identification plugin 'app_sketch_local' (identify_app_by_tcp_payload / identify_app_by_user_define_attributes), and an embedded LuaJIT ('libelua') for user-defined protocol signatures (e.g. custom Modbus detection) — concurrent LUA script loading crashes the classification worker.

SAPP's packet-capture configuration parameter (capdatamodlel) documents up to 16 capture-driver modes including libpcap, PF_RING, and DPDK, plus a Geedge-proprietary "marsio" mode (value 12) built by MESA on top of DPDK, whose driver-specific configuration is explicitly stated to live at /opt/mrzcpd/etc -- confirming, from SAPP's own configuration documentation, the marsio-mrzcpd relationship already inferred elsewhere in the corpus.

SAPP's internal developer manual documents three generic "packet-send" interfaces exposed to every business plugin: MESA_kill_tcp (builds and sends a TCP RST matching the current flow's four-tuple/sequence numbers to forcibly terminate a connection), MESA_kill_tcp_synack (sends a forged SYN/ACK so the client can never complete a handshake with the real server), and MESA_inject_pkt (injects arbitrary application-layer payload toward either side of a flow). This confirms RST-injection and payload-injection are first-class, reusable platform primitives, not one-off code, and that mrzcpd is the mechanism that re-injects sapp-generated blocking packets into a mirrored/passive-tap link (consistent with taxonomy.yaml's mrzcpd note).

Primary-source MESA Lab wiki documentation confirms SAPP ("Stream Analyse Process Platform") is a plugin-based traffic-inspection engine achieving 10-40Gbps per hardware unit, deployable either inline (串联) or as a passive mirror tap (并联), and exposes core platform APIs available to any business-layer plugin for forging a TCP RST (MESA_kill_tcp), spoofing a fake SYN/ACK to block connection establishment (MESA_kill_tcp_synack), and injecting arbitrary application-layer data into an established flow (MESA_inject_pkt).

Commit history in the core sapp DPI engine repo (MESA_Platform/sapp) shows its RST-style blocking/injection path is internally called "欺骗包" (literally "deceptive/spoofed packet") injection, implemented via a sapp_inject_ctrl_pkt function that sends forged control packets to all devices opened through the marsio packet-I/O layer; ticket TSG-20317 documents active, ongoing optimization of "inject packet duplicate traffic detection" performance in this code path as of 2024.

The lirenjie/lrj_vxlan sapp-plugin repo (2019-2020) implements a mirror/re-inject packet-processing plugin for VXLAN-encapsulated traffic that defaults to DROP for all packets and explicitly distinguishes two traffic-handling modes, "回流" (return-flow/mirror-received) and "回注" (re-inject), consistent with the mrzcpd/marsio architecture where sapp's blocking decisions on mirrored traffic are re-injected into the link.

"stellar" (stellar/stellar-2022) is a plugin-based protocol-decoder SDK (packet_io, plugin_manager, session_manager modules, with HTTP and DNS decoder components under active development through 2022) that runs on a "marsio mode" packet-I/O backend, showing the DPI decode layer beneath sapp is a modular framework supporting pluggable per-protocol decoders beyond SSL/TLS alone.

"stellar" (git.mesalab.cn / geedgenetworks.com) is a C++ core DPI packet-processing engine with protocol decoders (HTTP, FTP, mail, QUIC, RTP, SIP, DTLS, SSL, DNS, SOCKS, stratum) and a dedicated packet-injection module (src/stellar/inject.cpp) with an extensive TCP-RST-injection test suite covering injection timed after SYN, SYN-ACK, first C2S payload, and sub-ACK. It integrates the MAAT rule engine (security_enforcer.cpp / scanner_maat.c, "Security enforcer maat plugin table"), the Marsio packet-I/O framework (marsio_io.cpp), and glimpse_detector as an integrated decoder plugin ("integration glimpse_detector", "rename to lpi plugin").

The tango/tsg-service-chaining-engine (SCE) repo implements TSG's traffic-steering core: it VXLAN-encapsulates and routes both "raw" and "decrypted" copies of a session (four tracked metadata directions) through a chain of up to 32 third-party "Service Functions", with explicit per-flow actions of block, bypass, forward, and rx_drop for both mirrored and inline-steered traffic, coordinating with SAPP, mrzcpd (packet capture/re-injection), and MAAT4 (rule engine) via control-plane messages.

TSG's field operations-and-maintenance toolkit (lijia/tsg_oam) runs certstore, kni, tfe, and tsgenv each as independent systemd services on TSG appliances, and includes a dedicated tsg_monit_intercept.py monitoring script alongside per-protocol monitors (tsg_monit_protocol_v3.py/v4.py) and a marsio-based traffic reader (get_traffic_by_marsio.py) -- showing the certstore/interception subsystem is treated as its own independently-monitored production service rather than an incidental sapp sub-feature.