An update-alternatives install script for mrzcpd (path /opt/tsg/mrzcpd/...) enumerates its full binary/service set: mrzcpd, mrtools-pinfo, mrpdump (packet dump), monit_stream/monit_device/ monit_obp, mrmarch, dpdk-hugepages.py/dpdk-devbind.py (DPDK NIC binding), and systemd units including mrapm_device/mrapm_stream/mrapm_obp and mrtunnat — confirming mrzcpd is a DPDK-based packet-capture-and-injection agent with a dedicated tunnel/NAT offload component (mrtunnat).
/opt/tsg/mrzcpd/bin/mrzcpd ... /opt/tsg/mrzcpd/bin/mrpdump ... /usr/lib/systemd/system/mrtunnat.service
Related findings
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.
A live tsg_master engine config file exposes a [RESET] section with concrete TCP-RST-injection parameters (NUM=1, SEED1=65535, SEED2=13, FLAGS=20, DIR=3, REMEDY=0), a [TRAFFIC_MIRROR] section confirming mirror-tap deployment (NIC_NAME="eth_vf_mirr"), a [MAAT] section wiring tsg_master directly to MAAT's subscriber-ID tables (TSG_OBJ_SUBSCRIBER_ID/TSG_DYN_SUBSCRIBER_IP), and a device tag "BeiJing-XXG" confirming this specific instance is a domestic Beijing deployment. A plaintext Kafka SASL credential (SASL_PASSWD="galaxy2019") is also exposed, and "galaxy" recurs as an internal project codename elsewhere in this batch (docker service path /home/galaxy, APP_BRIDGE_NAME).
The Xinjiang Mobile carrier traffic report (2023-05-15) states in its own QUIC-domain-ranking section that Xinjiang's intra-provincial traffic has begun carrying QUIC/HTTP3 (UDP-based) traffic that poses "a huge challenge" to the traditional parallel/out-of-band ("并联") traffic-access blocking method, and that effectively gatekeeping ("GK") UDP/QUIC traffic requires switching to an inline/in-path ("串联") blocking architecture — a direct internal admission that (as of mid-2023, in this province) the standard mirror-tap deployment could not reliably block QUIC.
The same SAPP manual documents mrzcpd's inline (串联) packet-re-injection subcomponent mrtunnat, configured at /opt/mrzcpd/etc/mrtunnat.conf: use_recent_tunnel=1 allows it to inject a packet with no prior session record, and use_link_info_table=1 makes it validate outer MAC, link_id, link_dir, and inner MAC against a live link-state table at /run/mrzcpd/mrmonit.tunnat before re-injecting a censor-forged packet onto the correct physical link.
An internal SAPP platform training/reference manual (marked "Geedge Networks Confidential And Proprietary") gives SAPP's full name as "Stream Analyse Process Platform" and documents its three-tier plugin architecture (platform / protocol-parsing / business layers, each loaded via dlopen), inline and mirror deployment modes at a stated 10-40 Gbps per box, tunnel-protocol support (GRE/MPLS/IPIP/IPv6-over-IPv4/Teredo), and the MESA_kill_tcp() plugin API that forges and sends RST packets to sever a monitored TCP connection, with the manual noting it was "originally used in mirror mode to send RST packets to block a TCP connection" and auto-retries until the connection is confirmed dead.
Two 2023 self-test reports (one co-signed by the Institute of Information Engineering, Chinese Academy of Sciences) describe a dedicated capture appliance, hardware model MESA-NF-3100 (2U, Xeon E5-2640V4, 256GB RAM, dual XL710 10GbE NICs, 8Gbps/device and 20-27Gbps/cluster), whose mirror-capture driver is started via `systemctl start mrzpd` (mrzcpd) alongside the sapp process, feeding a downstream 'nirvana_server' component.