[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-83835":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":22,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":30,"readmeContent":31,"aiSummary":10,"trendingCount":16,"starSnapshotCount":16,"syncStatus":32,"lastSyncTime":33,"discoverSource":34},83835,"nettools","baidu\u002Fnettools","baidu","A physical network blackbox monitoring toolkit with diagnostic and probing capabilities for link quality, path tracing, packet modification detection, loss localization, and bandwidth measurement, enabling end-to-end reliability in large-scale data centers.","https:\u002F\u002Fnettools.rpcx.io\u002F",null,"Go",126,19,51,1,0,3,71,44,77,"MIT License",false,"main",[25,26,27,5,28,29],"cloud","idc","monitor","network","pingmesh","2026-06-12 04:01:42","# nettools\n\n[English](README.md) | [中文](README_CN.md)\n\n[![Go Version](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FGo-1.26-blue.svg)](https:\u002F\u002Fgo.dev\u002F)\n[![License: MIT](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-MIT-yellow.svg)](LICENSE)\n[![Go Reference](https:\u002F\u002Fpkg.go.dev\u002Fbadge\u002Fgithub.com\u002Fbaidu\u002Fnettools.svg)](https:\u002F\u002Fpkg.go.dev\u002Fgithub.com\u002Fbaidu\u002Fnettools)\n[![CI](https:\u002F\u002Fgithub.com\u002Fbaidu\u002Fnettools\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002Fbaidu\u002Fnettools\u002Factions\u002Fworkflows\u002Fci.yml)\n\nA suite of network diagnostic tools developed by Baidu's physical network black-box monitoring team, including:\n- **bitflip**: Detects packet loss and bit-flip errors in large-scale physical networks.\n- **bitflip6**: IPv6 variant of bitflip for IPv6 network diagnostics.\n- **baize**: Configuration-driven continuous network quality monitoring tool for long-term deployment.\n- **lidar**: TCP SYN probing tool for network reachability detection — no server-side deployment required.\n- **mping**: Multi-target ICMP Echo ping tool with CIDR expansion, DNS resolution, hardware timestamping, and packet corruption detection.\n- **mping6**: IPv6 variant of mping for ICMPv6 Echo probing with packet corruption detection.\n\n> Produced by Baidu System Department\n\n\n## Installation\n\n```bash\ncurl -fsSL https:\u002F\u002Fnettools.rpcx.io\u002Finstall.sh | sh\n```\n\nOr install to a specific directory:\n\n```bash\nBINDIR=~\u002F.local\u002Fbin curl -fsSL https:\u002F\u002Fnettools.rpcx.io\u002Finstall.sh | sh\n```\n\nOr build from source:\n\n```bash\nmake build\n```\n\n\n## bitflip\n\n![](docs\u002Fbitflip.png)\n\nA high-frequency UDP probing tool for network bit-flip (packet corruption) and packet loss detection. Supports **unidirectional** loss and corruption detection — both client-side (round-trip) and server-side (one-way from client to server).\n\n**How it works:** The client sends a large volume of UDP packets per second to the server, which echoes them back unchanged. Both sides independently detect issues:\n\n- **Client side (round-trip):** Detects packet loss and bit-flip on the full round-trip path. If a packet was dropped in either direction, it is counted as loss. If bit-flip is detected in the returned payload, the five-tuple is logged.\n- **Server side (one-way):** Detects packet loss and bit-flip on the client-to-server direction only. Each packet carries the client's actual send count and starting port pair for the previous time window; the server uses these to compute one-way loss and reconstruct the complete set of expected port pairs — enabling per-five-tuple loss identification without tracking client state. The server auto-registers unknown clients on first packet — no pre-configuration required.\n\nBy comparing client-side and server-side loss, you can determine whether loss occurs on the **forward path** (client → server) or the **return path** (server → client).\n\n### Quick Start\n\n**Build:**\n```bash\nmake build\n```\n\n**Run server (on the remote host):**\n```bash\n# Simplest — auto-detects local IP\n.\u002Fbitflip\n\n# With explicit IP\n.\u002Fbitflip -r server -s \u003Cserver_ip> -c \u003Cclient_ip>\n```\n\n**Run client (on the local host):**\n```bash\n# -c auto-detected if empty, -s is required\n.\u002Fbitflip -r client -s \u003Cserver_ip>\n\n# With explicit IPs\n.\u002Fbitflip -r client -c \u003Cclient_ip> -s \u003Cserver_ip>\n```\n\n### Command-line Flags\n\n| Short | Long | Default | Description |\n|-------|------|---------|-------------|\n| `-r` | `--role` | server | Role: client or server |\n| `-c` | `--client-addr` | \"\" | Client IP address (auto-detected if empty) |\n| `-s` | `--server-addr` | \"\" | Server IP address (auto-detected for server role if empty) |\n| `-t` | `--tos` | 64 | IP TOS\u002FDSCP value |\n| `-n` | `--count` | 0 | Max packets to send (0 = unlimited) |\n| `-d` | `--duration` | 0 | Max send duration (0 = unlimited) |\n| | `--client-ports` | \"43500,43599\" | Client port range [min,max] |\n| | `--server-ports` | \"43500,43509\" | Server port range [min,max] |\n| | `--rate` | 5000 | Packets per span |\n| | `--msglen` | 1024 | Message payload size (excluding 32-byte header) |\n| | `--delay` | 3s | Delay before processing stats (waiting for in-flight packets) |\n| | `--verbose` | false | Print per-port loss details on packet loss (both client and server) |\n\n### Examples\n\n```bash\n# Server side — auto-detect, no need to specify -c\n# Server auto-registers unknown clients on first packet\n.\u002Fbitflip\n\n# Client side\nsudo .\u002Fbitflip -r client -s 10.0.0.2\n\n# Client with custom rate and duration\nsudo .\u002Fbitflip --role client --server-addr 10.0.0.2 --rate 10000 --duration 60s\n\n# Client with verbose loss port details\nsudo .\u002Fbitflip -r client -s 10.0.0.2 --verbose\n\n# Server with verbose loss port details (per-five-tuple loss)\n.\u002Fbitflip -s 10.0.0.1 --verbose\n```\n\n### Bit-flip Detection\n\nThe client sends packets padded with 4 salt patterns, selected by `seq % 4`:\n\n| Index | Pattern | Description |\n|-------|---------|-------------|\n| 0 | `0xFF` | All-ones byte |\n| 1 | `0x00` | All-zeros byte |\n| 2 | `0x5A` | Fixed pattern `01011010` |\n| 3 | Complementary alternating | `0xAAAA` \u002F `0x5555` alternating 16-bit words |\n\nThe server uses the same 4 salt patterns to validate packets, ensuring accurate identification of which bytes have been flipped.\n\n### Packet Format\n\n```\n+----------+----------+-----------+---------------+------------------+------------------+----------+\n| Magic(8) | Seq(8)   | Ts(8)     | LastSent(4)   | LastSrcPort(2)   | LastDstPort(2)   | Salt(N)  |\n+----------+----------+-----------+---------------+------------------+------------------+----------+\n```\n\n- **Magic**: 8-byte magic flag identifier\n- **Seq**: 8-byte sequence number\n- **Ts**: 8-byte nanosecond timestamp\n- **LastSent**: 4-byte previous span send count\n- **LastSrcPort**: 2-byte previous span starting source port\n- **LastDstPort**: 2-byte previous span starting destination port\n- **Salt**: N-byte padding data (for bit-flip detection)\n\nThrough this compact protocol design, the server can reconstruct every port pair from the previous span using `(LastSrcPort, LastDstPort, LastSent)` and the deterministic `GetNextPorts` algorithm — enabling **server-side unidirectional loss detection with per-five-tuple granularity**, without the server needing to track client-side send state.\n\n## bitflip6\n\nIPv6 variant of bitflip. Usage is identical to bitflip, with IPv6 addresses:\n\n```bash\n# Server side\n.\u002Fbitflip6\n\n# Client side\nsudo .\u002Fbitflip6 -r client -s fd00::2\n```\n\n## mping\n\nA multi-target ICMP Echo ping tool for batch network quality inspection. Supports CIDR range expansion, DNS hostname resolution, hardware timestamping (Linux), high-rate probing, and packet corruption detection. mping6 is the IPv6 variant.\n\n**Key features:**\n- **CIDR expansion:** Pass a network prefix (e.g. `10.0.1.0\u002F24`) and mping automatically expands to all host addresses. IPv6 supports `\u002F112`–`\u002F128` prefixes with a `--max-targets` safety cap.\n- **DNS resolution:** Pass hostnames and mping resolves them automatically (A records for mping, AAAA for mping6).\n- **Hardware timestamps:** Enabled by default on Linux via `SO_TIMESTAMPING` for nanosecond latency accuracy. Falls back to software timestamps on macOS.\n- **Rate control:** Built-in token bucket rate limiter for precise per-target pps control.\n- **Multi-target:** Comma-separated IPs, CIDR ranges, and DNS hostnames can be mixed freely.\n- **Packet corruption detection:** Detects bit-flip errors in ICMP reply payloads by embedding known salt patterns in each probe packet.\n\n### Quick Start\n\n**Build:**\n```bash\nmake compile\n```\n\n**Run:**\n```bash\n# Single target (default 100 pps)\nsudo .\u002Fmping -T 10.0.0.2\n\n# Multiple targets\nsudo .\u002Fmping -T 10.0.0.2,10.0.0.3,10.0.0.4\n\n# CIDR range — probe entire \u002F24\nsudo .\u002Fmping -T 10.0.1.0\u002F24\n\n# DNS hostname\nsudo .\u002Fmping -T www.example.com\n\n# High rate for 30 seconds\nsudo .\u002Fmping -T 10.0.0.2 -r 1000 -d 30s\n\n# IPv6\nsudo .\u002Fmping6 -T fd00::2\n```\n\n### Command-line Flags (mping)\n\n| Short | Long | Default | Description |\n|-------|------|---------|-------------|\n| `-T` | `--targets` | — | Target IPv4 addresses\u002FCIDR\u002Fhostnames, comma-separated (required) |\n| `-l` | `--local-addr` | auto | Local IP address |\n| `-I` | `--interface` | auto | Outgoing interface name |\n| `-z` | `--tos` | 0 | IP TOS\u002FDSCP value |\n| | `--ttl` | 64 | IP TTL |\n| `-c` | `--count` | 0 | Max packets per target (0 = unlimited) |\n| `-d` | `--duration` | 0 | Max send duration (0 = unlimited) |\n| | `--delay` | 3s | Delay before processing stats |\n| `-t` | `--timeout` | 1s | Socket read timeout |\n| `-r` | `--rate` | 100 | Packets per second per target |\n| `-s` | `--size` | 64 | ICMP payload size in bytes (min: 8) |\n| | `--verbose` | false | Print per-reply ICMP details |\n| | `--hwts` | true | Enable hardware timestamping |\n| | `--max-targets` | 65536 | Max targets after CIDR\u002FDNS expansion |\n| `-V` | `--version` | false | Print version and exit |\n\nmping6 has the same flags with IPv6 equivalents (e.g. `--tc` instead of `--tos`, `--hlim` instead of `--ttl`).\n\nSee [mping usage guide](docs\u002Fmping.html) for more details.\n\n## baize\n\nA configuration-driven continuous network quality monitoring tool for long-term deployment. Unlike bitflip's command-line flag approach, baize uses a JSON config file and supports running both Client and Server in a single process.\n\n**Key features:**\n- **Config-driven:** All parameters managed via JSON config file, easy for automated deployment.\n- **Single-process dual-role:** Run Client and Server together in one process.\n- **Log rotation:** Built-in daily log rotation with automatic cleanup of expired files and symlink to the latest log.\n- **pprof integration:** Built-in Go pprof HTTP server for runtime profiling.\n- **Graceful shutdown:** Listens for SIGINT\u002FSIGTERM and gracefully shuts down all goroutines.\n\n> The internal version of baize used in Baidu's physical network also supports periodically pulling configuration from a database and pushing data to Kafka for aggregation. The open-source version is simplified to use config files only and output to logs by default, but provides interfaces for custom implementations.\n\n### Use Cases\n\n- **Inter-cluster high-frequency probing:** Continuous monitoring between large-scale clusters; high-frequency probing (default 5000 pps) quickly exposes intermittent packet loss; multi-port coverage of ECMP paths for pinpointing faulty links.\n- **LCC datacenter probing:** Cross-LCC datacenter network quality monitoring; configuration-driven deployment across multiple datacenter nodes.\n- **ADC\u002FDC network migration monitoring:** Continuous monitoring during network equipment cutover and upgrades; before\u002Fafter quality comparison to quantify migration impact; automatic detection of packet loss and corruption introduced by changes.\n- **Dedicated line monitoring:** Carrier dedicated line quality monitoring; real-time alerts for loss and latency anomalies; data support for SLA evaluation.\n- **Failback verification:** Network quality verification after traffic failback from disaster recovery; confirming no packet loss or bit-flip on the failback path.\n- **Ad-hoc point-to-point monitoring:** Temporary end-to-end probing for troubleshooting; minimal configuration to get started (only requires both IPs); easy to stop after verification.\n\n### Quick Start\n\n**Build:**\n```bash\ngo build -o baize .\u002Fcmd\u002Fbaize\u002F\n```\n\n**Create a config file** (e.g., `baize.json`):\n```json\n{\n  \"pprof_addr\": \":6060\",\n  \"log_dir\": \"\u002Fvar\u002Flog\u002Fbaize\",\n  \"log_max_age_days\": 7,\n  \"client\": {\n    \"client_addr\": \"10.0.0.1\",\n    \"server_addrs\": \"10.0.0.2\",\n    \"rate_in_span\": 5000,\n    \"span\": \"1s\",\n    \"delay\": \"3s\",\n    \"msg_len\": 1024,\n    \"tos\": 64\n  },\n  \"server\": {\n    \"server_addr\": \"10.0.0.2\",\n    \"client_addrs\": \"10.0.0.1\",\n    \"rate_in_span\": 5000,\n    \"span\": \"1s\",\n    \"delay\": \"3s\",\n    \"msg_len\": 1024,\n    \"tos\": 64\n  }\n}\n```\n\n**Run:**\n```bash\n# Use default config file (baize.json)\nsudo .\u002Fbaize\n\n# Specify config file path\nsudo .\u002Fbaize -c \u002Fetc\u002Fbaize\u002Fbaize.json\n```\n\n### Config Reference\n\n**Top-level fields:**\n\n| Field | Type | Default | Description |\n|-------|------|---------|-------------|\n| `pprof_addr` | string | \"\" | pprof HTTP listen address (e.g. `:6060`), empty to disable |\n| `log_dir` | string | \"\" | Log file directory, empty to output to stderr |\n| `log_max_age_days` | int | 7 | Log retention days (≤0 defaults to 7) |\n| `client` | object | null | Client config, null to skip |\n| `server` | object | null | Server config, null to skip |\n\n**Client\u002FServer fields:**\n\n| Field | Type | Default | Description |\n|-------|------|---------|-------------|\n| `client_addr` \u002F `server_addr` | string | \"\" | Local IP address |\n| `server_addrs` \u002F `client_addrs` | string | \"\" | Remote IP address(es), comma-separated |\n| `tos` | int | 0 | IP TOS\u002FDSCP value |\n| `client_port_range` | string | \"\" | Client port range `min,max` |\n| `server_port_range` | string | \"\" | Server port range `min,max` |\n| `rate_in_span` | int64 | 0 | Packets per span |\n| `span` | string | \"0s\" | Stats time window (Go duration) |\n| `delay` | string | \"0s\" | Stats processing delay |\n| `msg_len` | int | 0 | Message payload size (excluding 32-byte header) |\n| `count` | int | 0 | Max packets to send, client only (0 = unlimited) |\n| `send_duration` | string | \"0s\" | Max send duration, client only (0 = unlimited) |\n| `verbose` | bool | false | Print per-port loss details |\n\nSee [baize usage guide](docs\u002Fbaize-usage-guide.html) for more details.\n\n## lidar\n\nA TCP SYN probing tool for network reachability detection. It sends raw TCP SYN packets to target IPs and classifies responses as available (SYN-ACK), denied (RST), or unreachable (timeout). No server-side deployment needed — it leverages the target host's kernel TCP stack to respond to SYN packets.\n\n**How it works:** lidar constructs raw IP + TCP SYN packets via raw sockets, sends them to target IPs, and captures responses via BPF devices (macOS) or raw sockets (Linux). The kernel TCP stack does not process these packets, so existing TCP connections are unaffected.\n\n**Key features:**\n- **No server needed:** Only requires target IP + port. The target kernel automatically responds to SYN — no software installation required on the remote side.\n- **Precise classification:** Distinguishes SYN-ACK (port open), RST (port closed\u002Frejected), and timeout (unreachable\u002Fpacket loss).\n- **Source port rotation:** Automatically rotates source ports across a configurable range to cover multiple ECMP paths.\n- **Rate limiting:** Built-in token bucket rate limiter for precise probing frequency control.\n- **Multi-target:** Supports comma-separated target IPs with independent per-target statistics.\n\n### Quick Start\n\n**Build:**\n```bash\ngo build -o lidar .\u002Fcmd\u002Flidar\u002F\n```\n\n**Run:**\n```bash\n# Probe a single target on port 80 (default 10 pps)\nsudo .\u002Flidar -t 10.0.0.2 -p 80\n\n# Probe multiple targets\nsudo .\u002Flidar -t 10.0.0.2,10.0.0.3,10.0.0.4 -p 22\n\n# High rate probing for 30 seconds\nsudo .\u002Flidar -t 10.0.0.2 -p 80 --rate 100 -d 30s\n\n# Send exactly 1000 probes\nsudo .\u002Flidar -t 10.0.0.2 -p 80 -n 1000\n\n# Verbose mode with per-port loss details\nsudo .\u002Flidar -t 10.0.0.2 -p 80 -v\n```\n\n### Command-line Flags\n\n| Short | Long | Default | Description |\n|-------|------|---------|-------------|\n| `-t` | `--targets` | — | Target IP addresses, comma-separated (required) |\n| `-p` | `--port` | 22 | Target TCP port |\n| `-l` | `--local-addr` | auto | Source IP address |\n| | `--local-port` | 54321 | Source port base |\n| | `--local-port-count` | 100 | Number of source ports for rotation |\n| | `--rate` | 10 | Packets per second (pps) |\n| `-s` | `--span` | 1s | Stats reporting interval |\n| | `--delay` | 3s | Delay before first stats report |\n| `-n` | `--count` | 0 | Max packets to send (0 = unlimited) |\n| `-d` | `--duration` | 0 | Max send duration (0 = unlimited) |\n| `-i` | `--interface` | auto | Outgoing interface name |\n| `-v` | `--verbose` | false | Print per-port loss details |\n\n### Output\n\n```\n2026\u002F06\u002F05 21:37:14 [INFO] probing 1 target(s) on port 80 from 192.168.1.14 (rate: 10 pps)\n2026\u002F06\u002F05 21:37:14 [INFO] bound BPF to en0 (DLT=1)\n2026\u002F06\u002F05 21:37:17 [WARN] 21:37:14, [192.168.1.14 -> 74.48.173.243], sent: 10, received: 10 (SYN-ACK: 10, RST: 0), timeout: 0\n2026\u002F06\u002F05 21:37:18 [INFO] 21:37:15, [192.168.1.14 -> 74.48.173.243], sent: 10, received: 10 (SYN-ACK: 10, RST: 0), timeout: 0\n```\n\n| Field | Description |\n|-------|-------------|\n| `sent` | Total probe packets sent in this time window |\n| `received` | Total responses received |\n| `SYN-ACK` | SYN-ACK responses (target port open) |\n| `RST` | RST responses (target port closed\u002Frejected) |\n| `timeout` | No response (unreachable\u002Fpacket loss) |\n\nSee [lidar usage guide](docs\u002Flidar.html) for more details.\n\n## Testing\n\n```bash\nmake test\n```\n\n## Test Coverage\n\n![](coverage.svg)\n\n## Contributing\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.\n\n## Security\n\nSee [SECURITY.md](SECURITY.md) for vulnerability reporting.\n\n## License\n\nThis project is licensed under the [MIT License](LICENSE).\n",2,"2026-06-11 04:11:36","CREATED_QUERY"]