Pakistan

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.

application.yml shows the service's entire runtime config (Kafka bootstrap servers, thread-pool sizing, HTTP client-pool tuning, etc.) is pulled live from a shared internal Nacos config server, filed under Nacos config group "Galaxy" with data-id "p19-file-sync-service" -- direct confirmation that Nacos organizes Galaxy's constituent microservices (including this Pakistan-site one) under a single logical group, consistent with the taxonomy's 40+-repo galaxy-data-platform description. Separately, KafkaConsumer.java shows the underlying Kafka bus enables SASL_PLAINTEXT authentication (PLAIN mechanism, username/password sourced from the same Nacos config) specifically when the configured broker address contains port 9094, implying at least two logically distinct Kafka listener classes (authenticated on 9094 vs. unauthenticated elsewhere) on the shared bus this file-sync pipeline consumes from.

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.

A thesis-project assignment for hidden-service (VPN/Proxy/Tor) identification via heterogeneous graph neural networks on flow logs sources its one day of training data from a database explicitly named 'tsg_galaxy_p19' — tying the internal TSG naming convention to the taxonomy's P19/WMS-UTR Pakistan site codename — accessed over an internal 'Information Harbor' (信息港) VPN, with ground-truth hidden-service IP labels supplied by the commercial IP-intelligence service spur.us.

At a Pakistan site (P19/MSH), Geedge identified that TCP RST-injection for a Deny action fails on asymmetric ('unidirectional') flows because the synthetic RST packet lacks GRE callid/routing context only present when both directions transit the same node. Two fixes are in progress: a dedicated third-layer packet-injection route, or a cluster-wide coordination mechanism ('SwarmKV') that syncs which policy a session matched across nodes so each node can independently inject its own side's interference packet.

A log-stream double-write Flink program (galaxy/tsg_olap/log-stream-doublewrite) was purpose-built and repeatedly updated for "P19" -- the internal codename for the Pakistan (WMS-UTR) TSG deployment -- replicating TSG session-record logs to a secondary sink, evidencing dedicated engineering investment in the Pakistan customer's log pipeline distinct from the base product.

Geedge Networks' 2023 new-hire onboarding deck gives a corporate timeline: TSG's first international market win (with a codename "Nezha" launching the same month) in September 2018, "网络叙事者" (CyberNarrator) launching November 2020, a "South Asia" country project landing August 2021 (overseas market expansion), and Geedge winning a bid as overall solution provider for an "East Africa" country project in May 2022 — timing and regions consistent with this corpus's existing Pakistan (WMS-UTR/P19) and Ethiopia (E21) site attributions, though the deck itself does not name the countries.

Geedge's internal company timeline dates the launch of 网络叙事者 (CyberNarrator) to November 2020, and states the company won a 'South Asian country' project in May 2021 (consistent with Pakistan/WMS-UTR) and, as overall solution provider, an 'East Africa country' project in May 2022 (consistent with Ethiopia/HDM) -- corroborating the export timeline for those two customers from the company's own materials rather than site-side evidence alone.

At a 'WMS-UTR' project deployment, Huawei DPI equipment operating alongside Geedge TSG at sites abbreviated TWA/PCAP/MSH independently applies a SIP-protocol Deny policy with IP allowlisting -- confirming TSG is deployed in a multi-vendor stack alongside Huawei DPI hardware at the same customer site, not as the sole detection layer.

TSG ships a first-class 'Mail Monitoring and Blocking' feature (confirmed in the product's own v24.08 deployment test checklist alongside HTTP/HTTPS Blocking, DNS Redirection and Monitoring, HTTPS Decryption, and HTTPS Manipulation) that parses SMTP/POP3/IMAP sessions to extract sender/recipient addresses. Field analysis at a Pakistan site found STARTTLS opportunistic encryption accounts for roughly 25-32% of mail sessions and measurably defeats this extraction -- when STARTTLS occurs, the session is logged but mail-address fields are empty. Engineering's response is to add an explicit flag field rather than recover the addresses.

In WMS-UTR, a third party named "百分点" (Baifendian, a Chinese big-data analytics company) requested TSG's SIP protocol logs; Geedge added a monitor policy and extended the log schema with SIP-specific fields to support the handoff.

sapp has a CPU-overload protection mechanism that bypasses inspection when new-session rate is high enough (observed: 71 threads, ~50K new TCP/sec, ~32K new UDP/sec at a P-POC site). Treated as by-design; only the specific reported instance wasn't reproducible.

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 URL-blocking (P19 site) failed to block a second, near-simultaneous TCP session Chrome opens per HTTP request when that session's first-data-packet arrival lagged the SYN by 45+ seconds, because TSG's connection 'opening timeout' parameter defaulted to 10s and expired first, letting the session fall out of tracked state. Fixed in a later release by raising the timeout to 60s.

The galaxy/deployment/online-config repo — the central field/site configuration store — maintains per-customer git branches named E21 (Ethiopia), P19 and P19-POC (Pakistan), and XJ (Xinjiang), each tracking dated "现场配置" (field configuration) commits pinned to specific TSG software versions (e.g. TSG 22.02, 21.11), directly corroborating the E21/P19/XJ site codenames already established in taxonomy and confirming ongoing, versioned field deployments as recently as 2023-07 (a "P19 23.07 online-config" branch commit).

Internal site codename "P" (seen as "P-POC" and "P19") likely denotes a Pakistan deployment; a June 2024 ticket coordinating an in-person visit by a Pakistani delegation to Geedge's Beijing office falls in the same period P-coded site tickets appear, offering loose corroboration.

galaxy/tsg_olap/p19-file-sync-service is a Kafka-consumer-driven Spring Boot file transfer service explicitly namespaced "p19" — matching the taxonomy's WMS-UTR/P19 Pakistan site codename — confirming a dedicated TSG-OLAP infrastructure component built specifically for the Pakistan deployment's file-sync/HOS-storage needs.

Confirms an active Pakistan TSG-OS deployment (ACC license servers 10.10.10.159/10.10.20.159, Sentinel HASP hardware-dongle licensing) as of October 2023, corroborating Pakistan as a live customer, consistent with Amnesty International's 2025 'Shadows of Control' report.

A Pakistan deployment (internally 'WMS-UTR'/'P19', sites including Karachi and Islamabad) ingests full RADIUS AAA and NAT-log traffic from four named mobile carriers -- Jazz, Zong, Ufone, and Telenor -- to correlate every monitored network session with the subscriber's phone number (RADIUS 'Calling Station ID'), in near-real-time (target latency <1s, degrading to ~1hr under 8x traffic growth). The correlation engine, internally called 'CyberNarrator' (网络叙事者), writes resolved identity objects directly into security-policy objects every ~10 seconds so blocking policy can reference specific subscribers by phone number. Base-station location data is also parsed from Radius traffic.

Internal project codenames decode to specific customers: M22 = Myanmar (operators Mytel, Ooredoo Myanmar, and ATOM; sites YGN=Yangon, MDY=Mandalay), K18 = Kazakhstan (site renamed Nur-Sultan to Astana in OLAP config), E21 = Ethiopia (operator Safaricom Ethiopia; sites ADAMA-PE/SSM-PE to KLT-IGW/SHQ-IGW), WMS-UTR = Pakistan.