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.

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.

This P19 (Pakistan) service is a pure Kafka-triggered file relay: for each Kafka record it deserializes a SysFileSync payload carrying a list of {source_oss_path, destination_oss_path} pairs alongside common_log_id, common_recv_time, common_schema_type, and processing_time -- fields matching the shared session/event-log schema used elsewhere in the MESA platform -- then HTTP-GETs each file from its source path and HTTP-POSTs it to its destination path. Distinct hosError/ossError/fileSyncError counters for the two legs (source read vs. destination write) show the two endpoints are operated as separate storage systems, one referred to in logs as "Hos" and the other as "Oss". Net effect: file objects tied to individually logged monitored sessions at the Pakistan site are relayed between storage tiers as a matter of routine pipeline operation, not just session metadata.

The repo galaxy/tsg_olap/p19-file-sync-service.bundle is a dedicated, site-scoped microservice explicitly namespaced for P19 -- this corpus's Pakistan deployment codename (site_codenames: "WMS-UTR / P19: Pakistan"). Its Docker image is built under the tsg/galaxy Harbor namespace (192.168.40.153:9080/tsg/galaxy/p19-file-sync-service), and its container WORKDIR/MAINTAINER are both "galaxy", directly confirming that Galaxy (the OLAP/big-data layer documented elsewhere in this taxonomy) ships individually-built, per-customer-site production services out of its tsg_olap subtree rather than only shared library code. The pom.xml calendar version (23.09.26) pins this specific build to Sept 26, 2023.

An 'ADC Hardware Installation and Configuration Guide' (v21.11) describes a modular chassis (Switch Sled, CPU Sled) matching taxonomy's Pakistan/WMS-UTR 'ADC hardware' reference, confirming ADC is a distinct deployed hardware line -- not just a site nickname -- with its own installation documentation separate from the TSG-X/TSG-7400 line.