tsg_master

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).

TSG's DNS enforcement plugin (tango/fw_dns_plug, packaged with tsg_master) implements DNS response spoofing as its DENY action, sending forged/deceptive DNS answers, with differentiated behavior for mirror (passive-tap) vs inline deployments: mirror mode only spoofs a response to the request, while inline mode drops the real answer and injects a forged one.

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 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.

TSG's core traffic-processing daemon is named tsg_master (GitLab repo git.mesalab.cn/tango/tsg_master, part of the "TSG Appliance" project group). A 2023-07 field incident (site "P19") showed a single-core deadlock in tsg_master's log-sending path (function tsg_send_log) causing 100% CPU on one thread and packet loss; fixed in tsg_master-6.0.38 and shipped via the tsg-os-buildimage repo.

The tsg_master core DPI/blocking daemon's GitLab repository carries a dedicated long-lived branch "dev-K18" alongside version-numbered TSG-OS release branches, confirming Kazakhstan (K18) receives its own customer-specific development branch of the product's core traffic engine, not just configuration-level customization.

TSG's core traffic-processing daemon (tango/tsg_master) added explicit support for treating Encrypted ClientHello (ECH) as a security-policy match condition (TSG-15163/TSG-15711) and tags app_full_path output with ESNI and ECH markers (TSG-15779), meaning field TSG deployments can write and enforce policy rules that specifically key on ECH/ESNI usage rather than only on plaintext SNI.

tsg_master computes and logs JA3 TLS ClientHello fingerprints (feature present since at least 2020, field renamed common_ja3_fingerprint -> common_ja3_hash; toggle GENERATE_JA3_FINGERPRINT added 2023) and, since 2023, also outputs OS-fingerprint log fields (common_client_os_name, common_server_os_name), plus improved SSL/TLS detection when the ClientHello is split across multiple TCP segments.

tsg_master resolves IP:port sessions to a carrier Subscriber ID and mobile identifiers (IMSI/IMEI/APN/MSISDN) via dynamic MAAT lookup tables synced at runtime (TSG-17219, TSG-16294), a capability present since at least 2021 (TSG-8084, DYNAMIC_MAAT_SWITCH). This subscriber-identity resolution runs inside the core DPI/blocking daemon itself, not only in the separate CyberNarrator subsystem already documented in this corpus.