Skip to content

SCYTHE Offline PCAP Hypergraph Bundle

(no keyboard mouse nodes list controls) session-hypergraph-SESSION-d12ca4a0Download
(with arrow key and mouse nodes list control) session-hypergraph-SESSION-6eaf99d8Download

(with the multi tool tips) session-hypergraph-SESSION-3ef02645 (1)Download

(a tiny Hypergraph) session-hypergraph-SESSION-7a94edecDownload

Date: April 14, 2026  

Author: NerfEngine Team

—

There’s a class of debugging session that starts with a `SyntaxError` at line 22,749 and ends with you having built something you didn’t know you needed.

This is that story.

—

## The Problem Nobody Talks About

PCAP analysis tools share a universal sin: they’re built for the server. Fire up Wireshark, run the capture, open the UI, done. The assumption is that you have a network connection, a running backend, and a browser that can reach it. That assumption breaks the moment you’re doing forensic work on an air-gapped machine, briefing from a laptop on a plane, or handing a dataset to someone who shouldn’t have backend access.

The NerfEngine session hypergraph exporter was supposed to solve this. Capture a PCAP session — flows, hosts, ASNs, TLS SNIs, DNS names, port hubs — resolve it into a hypergraph, and export a **single standalone HTML file** that anyone can open offline and explore. No server. No dependencies. Just the data and a renderer.

The first version worked. Sort of. Open it in Chrome and you’d get:

“`

SyntaxError: Invalid or unexpected token  (line 22749)

“`

And separately:

“`

Unsafe attempt to load URL file:///… from frame with URL file:///…

‘file:’ URLs are treated as unique security origins.

“`

Plus, once the syntax error was fixed: an 1,100-node graph that would immediately consume every GPU cycle Chrome was willing to give it.

Three problems. Each one pointed to a deeper architectural decision.

—

## Problem One: The CDN Trap

The `SyntaxError` had nothing to do with the PCAP data. It was coming from an OrbitControls CDN script embed.

The bundle fetched Three.js and OrbitControls at generation time and inlined them as `<script>` blocks. The OrbitControls URL pointed to `three@0.149.0/examples/js/controls/OrbitControls.js`. That path doesn’t exist — Three.js removed the `examples/js/` UMD directory in r129. jsDelivr, rather than returning a 404, returns a plain-text error string: `”Couldn’t find the requested file in the three package”`.

That string gets embedded verbatim as a `<script>` block. The browser tries to parse the English sentence as JavaScript. Line 22,749 is somewhere deep inside that error message. The browser fails. The entire bundle is dead.

The fix was precise: pin to `three@0.125.2`, the last version with a UMD OrbitControls at that path. Both CDN URLs return valid JavaScript. Both verify HTTP 200 with `curl -I`. The bundle boots.

This is why you pin CDN dependencies.

—

## Problem Two: The Data Landfill

The original architecture was:

“`html

<script>

const DATA = { /* 50MB JSON blob */ }

</script>

“`

Everything baked into a single monolithic inline block. Fine for small graphs. Catastrophic at 1,000+ nodes with dense edge structure.

The fix was a **streaming NDJSON loader** — one JSON object per line, consumed incrementally via the File Streams API:

“`js

async function streamNDJSON(file, onItem) {

  const reader = file.stream().getReader();

  const decoder = new TextDecoder();

  let buffer = ”;

  while (true) {

    const { value, done } = await reader.read();

    if (done) break;

    buffer += decoder.decode(value, { stream: true });

    const lines = buffer.split(‘\n’);

    buffer = lines.pop();

    for (const line of lines) {

      if (line.trim()) onItem(JSON.parse(line));

    }

  }

}

“`

Zero parsing explosion. No main-thread blockage. Works entirely from `file://` using `input[type=file]` and drag-and-drop — no fetch, no server, no cross-origin requests. The `file://` security warning Chrome emits is cosmetic; it fires for any `file://` page with a null-origin frame, but all resources are inlined, so nothing is actually blocked.

Nodes hydrate the graph incrementally. The renderer schedules redraws via `requestAnimationFrame`, batching updates to avoid GPU thrash.

—

## Problem Three: The 3D Renderer

Once the bundle was stable and loading, the graph needed to actually be *usable* — not just renderable.

The session hypergraph for a typical PCAP capture at 1,000+ nodes is a **hairball** unless the interface gives you a way to isolate signal from noise. Every node is connected. Every connection is visually equal. Without a selection system, you’re looking at a dense sphere of lines and spheres that tells you nothing.

The solution was a bidirectional selection pipeline: clicking a node in the Three.js view highlights the corresponding row in the sidebar node list, and clicking a sidebar row highlights the corresponding mesh in the 3D scene. Scroll-into-view, label panel, threat score — all wired. A single `_bundleSelectNode(id, origin)` function handles both directions, with an `origin` parameter so a list-click doesn’t pointlessly switch the active tab and a 3D click does.

This got us to a working selection system. But the visual effect was still binary: selected node bright, everything else invisible. Useful for isolation. Not useful for understanding the neighborhood.

—

## The Signal Gradient

The real breakthrough was treating graph distance as a signal property.

When you select a node in a real network graph, you don’t just want to see that node. You want to understand its **context** — what connects directly to it, what connects to those connections, and where the neighborhood ends and the background begins. Binary visibility destroys that context. What you want is **structured falloff**: the selected node dominates, its direct neighbors are visible and colored to indicate their relationship, second-hop nodes whisper, and everything beyond three hops fades to near-zero.

We implemented this as a BFS-based distance map computed on click:

“`js

function bfsDistances(startId, adj, maxDepth) {

  const distances = { [startId]: 0 };

  const queue = [startId];

  while (queue.length) {

    const curr = queue.shift();

    const d = distances[curr];

    if (d >= maxDepth) continue;

    for (const nb of (adj[curr] || [])) {

      if (distances[nb] === undefined) {

        distances[nb] = d + 1;

        queue.push(nb);

      }

    }

  }

  return distances;

}

“`

The adjacency map is built lazily from the edge list on first selection and cached for the session. BFS is cheap at 1,000 nodes — under a millisecond. The result is a distance map keyed by node ID.

That distance map drives four independent visual channels simultaneously:

| Hop distance | Opacity | Emissive color | Pulse scale |

|—|—|—|—|

| 0 — selected | 1.0 | white | 1.5× |

| 1 — direct neighbors | 0.70 | cyan `#00e5ff` | 1.15× |

| 2 — two hops | 0.35 | dim blue `#004499` | 1.05× |

| 3 hops | 0.15 | black | 1.0× |

| 4+ — background | 0.06 | black | 1.0× |

Each tier’s emissive value is stored in `mesh.userData._gradientEmissive`. The hover system reads this to restore the correct emissive when the cursor leaves a mesh — so hovering any node temporarily shows it at full white (a “peek” effect), then restores its exact tier color when you move away. This keeps hover informative without destroying the gradient state.

The animation loop uses `mesh.userData.targetScale` instead of a hard-coded scale factor, so the gentle breathing pulse of each node reflects its distance from the selection point — neighbors breathe slightly larger, background nodes breathe at rest.

—

## Edge Intelligence

Nodes were only half the picture. The edge layer needed the same treatment.

The challenge: all dyadic edges in the Three.js renderer are batched into a single `THREE.LineSegments` object with vertex colors. There’s no per-edge opacity toggle — the material opacity is a global uniform. To create per-edge visual weight, we needed to rebuild the vertex color buffer on each selection.

When a node is selected, we iterate the `links` array (each entry carries `source.id` and `target.id`) and compute a brightness scale based on the minimum hop distance of the two endpoints:

“`

min(d[source], d[target]) == 0  →  scale 1.00

min(d[source], d[target]) == 1  →  scale 0.55

min(d[source], d[target]) == 2  →  scale 0.22

min(d[source], d[target]) == 3  →  scale 0.08

otherwise                       →  scale 0.02

“`

The base colors (stored at render time in `window._graphEdgeBaseColors`) are multiplied by this scale and written back into the `BufferAttribute`. One `needsUpdate = true` call, one GPU upload, and the edge layer recalculates in a single frame. No geometry rebuild. No draw call overhead. Material opacity is set to 1.0 so the brightness is entirely encoded in the vertex colors.

The result: edges connecting the selected node and its direct neighbors are fully illuminated. Two-hop connections are faint but visible. Background wiring disappears into the dark.

—

## Hyperedge Behavior

The session hypergraph includes hyperedges — relationships that connect more than two nodes simultaneously. A TLS session touching three hosts. A flow aggregate binding a source IP, destination port, and observed service. A DNS resolution chain through an intermediate nameserver.

These are rendered as centroid orbs with spokes to each member and a ring glow. Each hyperedge has three `THREE.Object3D` children in sequence: orb, spokes, ring.

The gradient applies to all three. For each hyperedge, we find the minimum hop distance across all its member nodes and select a tier. Hyperedges touching the selected node glow at near-full opacity. Hyperedges one hop away are dimmed but present. Distant hyperedges fade to barely-visible. On deselection, original opacities are restored from `userData._origOpacity`.

One subtle bug surfaced here during implementation: the init call that creates `window._graphHyperedgeMembers = []` was anchored to a comment that appears **after** the `hyperedges.forEach()` loop. The loop was trying to push member arrays into an array that didn’t exist yet. Moving the anchor one section up — to the comment immediately before the loop — fixed it.

This is a good reminder of what can go wrong when you’re patching function source strings at generation time rather than at definition time: execution order in the emitted code doesn’t always match the order you wrote the patches.

—

## The Architecture in Practice

The complete system is implemented inside `_buildSessionGraphBundle()` in `command-ops-visualization.html`. It works like this:

1. **Generation time**: The operator clicks the bundle button. The page fetches Three.js and OrbitControls from CDN (pinned to r125.2), runs the force simulation to pre-compute node positions, and calls `renderSession3DGraph.toString()` to extract the live renderer as a source string.

2. **Patching**: The renderer source is patched via a chain of `.replace()` calls that inject bundle-specific globals, expose scene objects to `window`, store edge geometry references, and modify the animation loop to read `userData.targetScale`.

3. **Bundle generation**: All of this — Three.js, OrbitControls, patched renderer, node/edge/hyperedge JSON, sidebar HTML, CSS — is assembled into a single `<html>` string and offered as a download.

4. **Offline playback**: The downloaded HTML opens in any browser with no server, no dependencies, no network. The Three.js scene initializes, the 3D force graph renders, and the full gradient selection system is live.

The patching mechanism is powerful but fragile. Every `.replace()` call depends on an exact string match against the function’s `.toString()` output. If a minifier touches the function, or if a future refactor changes a comment or variable name, the patch silently fails to apply. The postcondition check at the end of the patch chain (`if (!rendererSrc.includes(‘_graphMeshById’) || !rendererSrc.includes(‘_graphEdgeGeo’))`) catches the most critical failures.

—

## What It Looks Like

Select a `pcap_session` node representing an HTTPS flow to an ASN you haven’t seen before. What happens:

– The session node ignites in white with a 1.5× scale pulse.

– Its direct connections — the destination host, the TLS SNI, the source IP, the port hub — glow cyan. Their spokes to each other stay visible.

– Two hops out: the ASN node, the DNS name that resolved to the destination, the geo_point. Dim blue, barely breathing.

– Three hops: the org node above the ASN, the nameserver above the DNS name. Present, but whispering.

– Everything else: near-invisible, 6% opacity. The graph structure is still there — you can see the shape of the network — but it’s background radiation.

Click again on the same node. Selection clears. The graph exhales back to its default state: full opacity, base emissive, equal scale. Click the canvas background. Same reset. Click a sidebar row. The 3D camera doesn’t move, but the selected mesh lights up and the correct row gets highlighted.

This is the “controlled collapse of the graph around a point of interest” pattern. The selected node is the anchor. Its neighbors are the structure. Everything else is context.

—

## Technical Decisions Worth Noting

Why `.toString()` patching instead of a separate renderer module?

The bundle must be standalone. If the renderer were a separate module, the bundle would need a bundler (Webpack, esbuild) in the generation pipeline. Using `.toString()` means the renderer is always in sync with the live page — any fix applied to the live Three.js view is automatically reflected in the next bundle generated. The cost is patch fragility. The benefit is zero-maintenance synchronization.

Why pin to Three.js r125.2?

r126+ removed the `examples/js/` UMD directory. All newer versions use `examples/jsm/` ES modules, which require either a bundler or an importmap — neither works in a single-file offline bundle. r125.2 is the last version that ships `OrbitControls.js` as a global-scope UMD script that a `<script>` tag can load directly.

Why rebuild the vertex color buffer instead of using separate LineSegments per tier?

At 2,000+ edges, creating five separate `LineSegments` objects (one per opacity tier) on every node selection would generate significant GC pressure. Rebuilding a single `Float32Array` in place and flagging `needsUpdate = true` is a single GPU buffer upload. The selection system runs in under 2ms even at full graph scale.

Why lazy adjacency construction?

The BFS adjacency map is only needed when a node is selected. Building it at render time would add ~5ms to an already-expensive initialization path. Building it on first selection amortizes the cost to the moment it’s needed. The cache hit on subsequent selections is effectively zero.

—

## What’s Next

The bundle system currently exports a static snapshot of session state. The natural next evolution is temporal replay — the ability to scrub through the capture timeline and watch the hypergraph evolve. Nodes appear as flows begin. Edge weights change as traffic accumulates. Hyperedges form as correlation patterns emerge.

The NDJSON streaming architecture is already compatible with this. A timestamped NDJSON format would let the loader replay events at speed, with the gradient system showing which nodes are “hot” at any given moment.

The other frontier is weighted edge propagation. The current gradient uses hop count as a uniform distance metric. Real PCAP analysis has non-uniform edge weights — a flow with 50,000 packets is not the same distance as a flow with 3 packets. Running a damped signal propagation (`signal = exp(-λ × weight × distance)`) through the adjacency map would turn the gradient from a graph topology view into a traffic intensity field. The selected node’s gravity well would deform based on actual session volumes, not just connection existence.

That closes the loop from “I selected a host” to “show me where the traffic actually went.”

—

## Summary

The offline PCAP hypergraph bundle solves a real operational problem: delivering forensic-grade network intelligence to environments where you cannot run a backend. A single HTML file, air-gap safe, opens in any browser, and renders a complete session hypergraph with gradient-aware selection, bidirectional sidebar sync, and edge intelligence baked in.

The path to get there required:

– Pinning CDN dependencies to a specific known-good version

– Replacing monolithic JSON blobs with incremental streaming loaders  

– Building a selection system that works bidirectionally across UI layers

– Implementing BFS-based signal gradient that treats graph distance as a visual property

– Rebuilding vertex color buffers in-place for per-edge distance weighting

– Carefully managing execution order in patched renderer source strings

Every one of those steps was forced by a real constraint. The SyntaxError at line 22,749 was a pointer to an architectural decision that needed revisiting. The `file://` security warning was a nudge toward the right loading strategy. The GPU thrash was the graph saying it needed a focus model.

The result is a bundle that behaves less like a static export and more like a portable intelligence terminal.

—

HYPER_SCYTHE_Core is a local-first, RF-aware tactical intelligence platform. All inference runs on local hardware. No data leaves the edge.

|||||||||||||||||||||||||||||||||||||||||||

OfflineHyperGraphBunble_SocialPost04142026.pcap

2.8 MB • 115 sessions • TCP:98 ICMP:12 UDP:5

Session Hypergraph: SESSION-6eaf99d8f15e5e49

620 nodes • 1464 edges

KindIDLabelsPosition
asnasn:16276asn=16,276, org=OVH SAS
asnasn:14618asn=14,618, org=Amazon.com, Inc.
asnasn:4766asn=4,766, org=Korea Telecom
asnasn:7018asn=7,018, org=AT&T Enterprises, LLC
asnasn:31898asn=31,898, org=Oracle Corporation
asnasn:40788asn=40,788, org=Start Communications
asnasn:3170asn=3,170, org=VeloxServ Communications Ltd
asnasn:9145asn=9,145, org=EWE-Tel GmbH
asnasn:212567asn=212,567, org=Freie Netze Muenchen e.V.
asnasn:12876asn=12,876, org=Scaleway S.a.s.
asnasn:18209asn=18,209, org=Atria Convergence Technologies Ltd.
asnasn:204880asn=204,880, org=Stowarzyszenie Warszawski Hackerspace
asnasn:20473asn=20,473, org=The Constant Company, LLC
asnasn:47890asn=47,890, org=Unmanaged Ltd
asnasn:197540asn=197,540, org=netcup GmbH
asnasn:202425asn=202,425, org=IP Volume inc
asnasn:63949asn=63,949, org=Akamai Connected Cloud
asnasn:24940asn=24,940, org=Hetzner Online GmbH
asnasn:12392asn=12,392, org=VOO S.A.
asnasn:6167asn=6,167, org=Verizon Business
asnasn:138968asn=138,968, org=rainbow network limited
asnasn:208137asn=208,137, org=Feo Prest SRL
asnasn:18809asn=18,809, org=Cable Onda
asnasn:48090asn=48,090, org=Techoff Srv Limited
asnasn:13335asn=13,335, org=Cloudflare, Inc.
asnasn:24086asn=24,086, org=Viettel Corporation
hosthost:91.99.85.118bytes=35,019, city=Falkenstein, country=DE, ip=91.99.85.118, org=Hetzner Online GmbH[50.4777, 12.3649, 0.0000] 🌐
hosthost:172.234.197.23bytes=282, city=Chicago, country=US, ip=172.234.197.23, org=Akamai Connected Cloud[41.8835, -87.6305, 0.0000] 🌐
hosthost:185.242.226.114bytes=198, city=, country=US, ip=185.242.226.114, org=IP Volume inc[37.7510, -97.8220, 0.0000] 🌐
hosthost:103.115.41.16bytes=7,802, city=, country=CN, ip=103.115.41.16, org=rainbow network limited[34.7732, 113.7220, 0.0000] 🌐
hosthost:185.150.99.2bytes=9,446, city=Munich, country=DE, ip=185.150.99.2, org=Freie Netze Muenchen e.V.[48.1428, 11.5801, 0.0000] 🌐
hosthost:46.4.252.37bytes=34,677, city=Falkenstein, country=DE, ip=46.4.252.37, org=Hetzner Online GmbH[50.4777, 12.3649, 0.0000] 🌐
hosthost:184.171.210.134bytes=9,634, city=London, country=CA, ip=184.171.210.134, org=Start Communications[42.9867, -81.1808, 0.0000] 🌐
hosthost:109.89.117.44bytes=34,987, city=Milmort, country=BE, ip=109.89.117.44, org=VOO S.A.[50.6979, 5.5981, 0.0000] 🌐
hosthost:163.192.126.71bytes=33,946, city=Chicago, country=US, ip=163.192.126.71, org=Oracle Corporation[41.8486, -87.6288, 0.0000] 🌐
hosthost:185.236.240.137bytes=9,445, city=, country=PL, ip=185.236.240.137, org=Stowarzyszenie Warszawski Hackerspace[52.2394, 21.0362, 0.0000] 🌐
hosthost:172.3.50.214bytes=34,127, city=Romeoville, country=US, ip=172.3.50.214, org=AT&T Enterprises, LLC[41.6475, -88.0895, 0.0000] 🌐
hosthost:97.139.29.134bytes=456,758, city=Houston, country=US, ip=97.139.29.134, org=Verizon Business[29.6966, -95.5441, 0.0000] 🌐
hosthost:91.240.224.238bytes=33,929, city=London, country=GB, ip=91.240.224.238, org=VeloxServ Communications Ltd[51.5081, -0.1278, 0.0000] 🌐
hosthost:37.27.162.26bytes=9,537, city=Helsinki, country=FI, ip=37.27.162.26, org=Hetzner Online GmbH[60.1719, 24.9347, 0.0000] 🌐
hosthost:91.248.64.70bytes=9,518, city=Sottrum, country=DE, ip=91.248.64.70, org=EWE-Tel GmbH[53.1183, 9.2310, 0.0000] 🌐
hosthost:49.12.170.238bytes=9,661, city=Falkenstein, country=DE, ip=49.12.170.238, org=Hetzner Online GmbH[50.4777, 12.3649, 0.0000] 🌐
hosthost:116.99.174.160bytes=510, city=, country=VN, ip=116.99.174.160, org=Viettel Corporation[16.1667, 107.8333, 0.0000] 🌐
hosthost:195.154.100.87bytes=35,211, city=Paris, country=FR, ip=195.154.100.87, org=Scaleway S.a.s.[48.8558, 2.3494, 0.0000] 🌐
hosthost:94.130.10.221bytes=9,501, city=Falkenstein, country=DE, ip=94.130.10.221, org=Hetzner Online GmbH[50.4777, 12.3649, 0.0000] 🌐
hosthost:2.57.122.191bytes=5,554, city=, country=RO, ip=2.57.122.191, org=Unmanaged Ltd[45.9968, 24.9970, 0.0000] 🌐
hosthost:136.243.57.208bytes=35,257, city=Falkenstein, country=DE, ip=136.243.57.208, org=Hetzner Online GmbH[50.4777, 12.3649, 0.0000] 🌐
hosthost:67.219.103.9bytes=8,098, city=Melbourne, country=AU, ip=67.219.103.9, org=The Constant Company, LLC[-37.8159, 144.9669, 0.0000] 🌐
hosthost:2.57.121.25bytes=1,242, city=, country=RO, ip=2.57.121.25, org=Unmanaged Ltd[45.9968, 24.9970, 0.0000] 🌐
hosthost:45.148.10.151bytes=172, city=Amsterdam, country=NL, ip=45.148.10.151, org=Techoff Srv Limited[52.3759, 4.8975, 0.0000] 🌐
hosthost:5.75.182.251bytes=34,734, city=Nuremberg, country=DE, ip=5.75.182.251, org=Hetzner Online GmbH[49.4527, 11.0783, 0.0000] 🌐
hosthost:54.91.240.230bytes=8,512, city=Ashburn, country=US, ip=54.91.240.230, org=Amazon.com, Inc.[39.0469, -77.4903, 0.0000] 🌐
hosthost:65.108.246.230bytes=35,087, city=Helsinki, country=FI, ip=65.108.246.230, org=Hetzner Online GmbH[60.1719, 24.9347, 0.0000] 🌐
hosthost:49.207.40.162bytes=444, city=Delhi, country=IN, ip=49.207.40.162, org=Atria Convergence Technologies Ltd.[28.6542, 77.2373, 0.0000] 🌐
hosthost:185.207.107.155bytes=8,444, city=Nuremberg, country=DE, ip=185.207.107.155, org=netcup GmbH[49.4423, 11.0191, 0.0000] 🌐
hosthost:51.91.243.64bytes=34,123, city=, country=FR, ip=51.91.243.64, org=OVH SAS[48.8582, 2.3387, 0.0000] 🌐
hosthost:88.99.91.59bytes=8,384, city=Falkenstein, country=DE, ip=88.99.91.59, org=Hetzner Online GmbH[50.4777, 12.3649, 0.0000] 🌐
hosthost:118.33.70.70bytes=5,759, city=Seoul, country=KR, ip=118.33.70.70, org=Korea Telecom[37.5576, 126.9937, 0.0000] 🌐
hosthost:51.210.99.95bytes=9,505, city=, country=FR, ip=51.210.99.95, org=OVH SAS[48.8582, 2.3387, 0.0000] 🌐
hosthost:104.28.157.109bytes=35,110, city=San Jose, country=US, ip=104.28.157.109, org=Cloudflare, Inc.[37.3388, -121.8916, 0.0000] 🌐
hosthost:51.161.119.157bytes=8,607, city=, country=CA, ip=51.161.119.157, org=OVH SAS[43.6319, -79.3716, 0.0000] 🌐
hosthost:172.232.0.16bytes=282, city=Chicago, country=US, ip=172.232.0.16, org=Akamai Connected Cloud[41.8835, -87.6305, 0.0000] 🌐
hosthost:68.252.16.184bytes=9,584, city=Delray Beach, country=US, ip=68.252.16.184, org=AT&T Enterprises, LLC[26.4525, -80.1562, 0.0000] 🌐
hosthost:200.46.125.168bytes=1,740, city=Panama City, country=PA, ip=200.46.125.168, org=Cable Onda[8.9948, -79.5230, 0.0000] 🌐
hosthost:213.209.159.228bytes=316, city=, country=TW, ip=213.209.159.228, org=Feo Prest SRL[24.0000, 121.0000, 0.0000] 🌐
hosthost:57.128.95.174bytes=9,447, city=, country=FR, ip=57.128.95.174, org=OVH SAS[48.8582, 2.3387, 0.0000] 🌐
hosthost:147.135.97.222bytes=8,391, city=Oakton, country=US, ip=147.135.97.222, org=OVH SAS[38.8809, -77.3008, 0.0000] 🌐
orgorg:AT&T Enterprises, LLCname=AT&T Enterprises, LLC
orgorg:Techoff Srv Limitedname=Techoff Srv Limited
orgorg:VOO S.A.name=VOO S.A.
orgorg:Amazon.com, Inc.name=Amazon.com, Inc.
orgorg:Verizon Businessname=Verizon Business
orgorg:netcup GmbHname=netcup GmbH
orgorg:Oracle Corporationname=Oracle Corporation
orgorg:Stowarzyszenie Warszawski Hackerspacename=Stowarzyszenie Warszawski Hackerspace
orgorg:Cloudflare, Inc.name=Cloudflare, Inc.
orgorg:IP Volume incname=IP Volume inc
orgorg:Cable Ondaname=Cable Onda
orgorg:Freie Netze Muenchen e.V.name=Freie Netze Muenchen e.V.
orgorg:Viettel Corporationname=Viettel Corporation
orgorg:The Constant Company, LLCname=The Constant Company, LLC
orgorg:Scaleway S.a.s.name=Scaleway S.a.s.
orgorg:EWE-Tel GmbHname=EWE-Tel GmbH
orgorg:rainbow network limitedname=rainbow network limited
orgorg:Korea Telecomname=Korea Telecom
orgorg:Feo Prest SRLname=Feo Prest SRL
orgorg:Hetzner Online GmbHname=Hetzner Online GmbH
orgorg:Atria Convergence Technologies Ltd.name=Atria Convergence Technologies Ltd.
orgorg:OVH SASname=OVH SAS
orgorg:Start Communicationsname=Start Communications
orgorg:Akamai Connected Cloudname=Akamai Connected Cloud
orgorg:VeloxServ Communications Ltdname=VeloxServ Communications Ltd
orgorg:Unmanaged Ltdname=Unmanaged Ltd
Session IDProtoSourceDestinationPktsBytesDurationActions
SESSION-6eaf99d8f15e…TCP [FAP]172.234.197.23:22200.46.125.168:39366242.4K20.4s🔍 Graph
SESSION-5a64e15ed9dc…ICMP172.234.197.23:*116.99.174.160:*5510B15.5s🔍 Graph
SESSION-4a2c79ba5f63…TCP [FAP]172.234.197.23:22213.209.159.228:444464316B0.2s🔍 Graph
SESSION-8d7906394a77…TCP [FA]172.234.197.23:51590172.64.155.209:4433198B<1s🔍 Graph
SESSION-b359aca16c97…TCP [FAPS]172.234.197.23:42754172.64.155.209:4431610.7K4.2s🔍 Graph
SESSION-57744320478f…TCP [FAPS]118.33.70.70:42672172.234.197.23:22275.0K5.5s🔍 Graph
SESSION-1cb71bb22c44…TCP [AP]97.139.29.134:54827172.234.197.23:222883446.1K29.0s🔍 Graph
SESSION-8a73bee456a2…UDP172.234.197.23:53537172.232.0.16:532202B<1s🔍 Graph
SESSION-625d57134372…TCP [S]116.99.174.160:53092172.234.197.23:225370B15.5s🔍 Graph
SESSION-cf5e312cb9d9…TCP [AP]97.139.29.134:62896172.234.197.23:44391.6K0.2s🔍 Graph
SESSION-4ae26ca68376…TCP [APS]97.139.29.134:51449172.234.197.23:4435336.2K3.3s🔍 Graph
SESSION-195a8e5e5c99…TCP [APS]172.234.197.23:42756172.64.155.209:4432319.1K0.1s🔍 Graph
SESSION-602fbcf1561b…TCP [FA]172.234.197.23:38072104.18.32.47:4433198B<1s🔍 Graph
SESSION-12deb75317c2…TCP [FAPS]118.33.70.70:34342172.234.197.23:22345.6K7.1s🔍 Graph
SESSION-d9a20aed1136…ICMP172.234.197.23:*103.115.41.16:*202.1K18.8s🔍 Graph
SESSION-6dd3a0943014…TCP [FAPS]103.115.41.16:38472172.234.197.23:22637.6K24.7s🔍 Graph
SESSION-60a9b3494e46…TCP [APR]172.234.197.23:2245.148.10.151:450182172B0.1s🔍 Graph
SESSION-0414aa86fd0d…UDP172.234.197.23:52917172.232.0.16:532282B<1s🔍 Graph
SESSION-4c118e814292…ICMP172.234.197.23:*200.46.125.168:*141.7K20.2s🔍 Graph
SESSION-acf516f3fcbf…TCP [FA]172.234.197.23:51624172.64.155.209:4433198B<1s🔍 Graph
SESSION-59660ba8580a…TCP [FAPS]118.33.70.70:42682172.234.197.23:22275.0K3.2s🔍 Graph
SESSION-939e2783347e…UDP172.234.197.23:46758172.232.0.16:532226B0.1s🔍 Graph
SESSION-f1a32f24bb58…TCP [FA]185.242.226.114:38823172.234.197.23:4433198B0.1s🔍 Graph
SESSION-7609165a9467…TCP [FA]185.242.226.114:35229172.234.197.23:803198B0.1s🔍 Graph
SESSION-bb0012e89ee7…ICMP172.234.197.23:*118.33.70.70:*7694B1.7s🔍 Graph
SESSION-e7c80f4c12e4…TCP [AFPECS]2.57.121.25:31377172.234.197.23:22457.5K19.8s🔍 Graph
SESSION-ec131e7f6d9a…TCP [AFPRS]49.12.170.238:46722172.234.197.23:4434834.6K0.7s🔍 Graph
SESSION-ffe0542749bc…TCP [AFPRS]91.99.85.118:8524172.234.197.23:443219.3K0.5s🔍 Graph
SESSION-a4f732025af9…ICMP172.234.197.23:*200.46.125.168:*2252B2.0s🔍 Graph
SESSION-9dc81c1ae11f…TCP [AFPRS]51.161.119.157:15440172.234.197.23:443258.4K0.2s🔍 Graph
SESSION-6c448ec16dfc…TCP [AFPRS]147.135.97.222:59068172.234.197.23:4434333.2K0.5s🔍 Graph
SESSION-4cb9db2a9881…TCP [AFPRS]147.135.97.222:59070172.234.197.23:443218.2K0.3s🔍 Graph
SESSION-bda3a4211818…TCP [AFPRS]109.89.117.44:46882172.234.197.23:4434234.2K0.9s🔍 Graph
SESSION-9bff901a4efa…TCP [AFPRS]68.252.16.184:40478172.234.197.23:443239.4K0.5s🔍 Graph
SESSION-08d942f49f5a…TCP [FAPS]104.28.157.109:26598172.234.197.23:4434434.3K0.4s🔍 Graph
SESSION-d2ad000644ff…TCP [AFPRS]91.99.85.118:34235172.234.197.23:4434134.2K1.0s🔍 Graph
SESSION-9f69bc18abdf…TCP [AFPRS]54.91.240.230:64622172.234.197.23:443238.3K0.3s🔍 Graph
SESSION-9e920a0f92f5…TCP [APR]172.234.197.23:2245.148.10.151:450182172B0.1s🔍 Graph
SESSION-98bfd3520b98…TCP [AFPRS]51.210.99.95:43570172.234.197.23:443229.3K0.5s🔍 Graph
SESSION-9b1ee0275819…TCP [FAPS]67.219.103.9:39884172.234.197.23:443177.9K1.0s🔍 Graph
SESSION-fb96a1bdc701…TCP [AFPRS]91.248.64.70:64345172.234.197.23:4434434.3K0.9s🔍 Graph
SESSION-5fd2ff9698fd…TCP [FAPR]103.115.41.16:38472172.234.197.23:227568B25.7s🔍 Graph
SESSION-0ddcf3512b8d…TCP [AFPRS]91.240.224.238:57376172.234.197.23:443218.2K0.5s🔍 Graph
SESSION-f999e564d3d4…TCP [AFPRS]51.210.99.95:43560172.234.197.23:4434434.3K0.7s🔍 Graph
SESSION-032beee78275…TCP [AFPRS]91.240.224.238:57372172.234.197.23:4434233.1K0.7s🔍 Graph
SESSION-2043398bde7c…ICMP172.234.197.23:*118.33.70.70:*7682B23.3s🔍 Graph
SESSION-7eb52c259524…UDP172.234.197.23:34484172.232.0.16:532282B<1s🔍 Graph
SESSION-e810538a97e9…TCP [FAPS]104.28.157.109:26600172.234.197.23:443199.1K0.4s🔍 Graph
SESSION-b962b69ea66a…TCP [A]172.234.197.23:42756172.64.155.209:4434264B15.4s🔍 Graph
SESSION-e59fa20cda39…TCP [AFPRS]185.236.240.137:50242172.234.197.23:443219.2K0.7s🔍 Graph
SESSION-a9e0c6718d07…TCP [FAP]172.234.197.23:22200.46.125.168:393663314B2.1s🔍 Graph
SESSION-5094f839eafc…ICMP172.234.197.23:*2.57.121.25:*91.2K3.6s🔍 Graph
SESSION-58716031a6c5…TCP [AFPRS]49.12.170.238:46736172.234.197.23:443249.4K0.6s🔍 Graph
SESSION-9e17949ff29d…TCP [AFPRS]68.252.16.184:40474172.234.197.23:4434634.4K0.4s🔍 Graph
SESSION-c02e703447b8…TCP [AFPRS]54.91.240.230:64614172.234.197.23:4434533.3K0.3s🔍 Graph
SESSION-a8248a28262e…TCP [AP]97.139.29.134:51449172.234.197.23:44392.0K0.2s🔍 Graph
SESSION-d4de946fb17e…TCP [AFPRS]51.161.119.157:15008172.234.197.23:4434533.3K0.3s🔍 Graph
SESSION-c7db653acb66…TCP [AFPRS]109.89.117.44:46898172.234.197.23:443229.3K0.5s🔍 Graph
SESSION-58b8c266a442…TCP [AP]97.139.29.134:62896172.234.197.23:443295.1K19.8s🔍 Graph
SESSION-cb6d706f4df4…TCP [AFPRS]67.219.103.9:39880172.234.197.23:4434633.4K1.9s🔍 Graph
SESSION-5df662d2859b…TCP [AP]97.139.29.134:54827172.234.197.23:222583395.7K29.9s🔍 Graph
SESSION-c22342fbfdd5…TCP [AFPRS]185.207.107.155:34680172.234.197.23:4433932.9K0.7s🔍 Graph
SESSION-9e3444090b61…TCP [AFPRS]91.248.64.70:64574172.234.197.23:443229.3K0.7s🔍 Graph
SESSION-eef359651363…TCP [AFPRS]185.236.240.137:50234172.234.197.23:4434234.2K0.8s🔍 Graph
SESSION-14f607dbc01e…TCP [AFPRS]185.207.107.155:34696172.234.197.23:443228.2K0.6s🔍 Graph
SESSION-2741341230d4…ICMP172.234.197.23:*103.115.41.16:*6618B25.7s🔍 Graph
SESSION-3daac4bac753…TCP [FAPR]172.234.197.23:22118.33.70.70:3434211958B23.5s🔍 Graph
SESSION-3033c7795363…TCP [AFPRS]195.154.100.87:37146172.234.197.23:4434534.4K0.7s🔍 Graph
SESSION-70604a34ea16…TCP [AFPRS]88.99.91.59:54648172.234.197.23:443218.2K0.5s🔍 Graph
SESSION-9215fe09255e…TCP [AFPRS]57.128.95.174:39308172.234.197.23:443219.2K0.5s🔍 Graph
SESSION-4b98f1f466d3…TCP [A]172.234.197.23:42756172.64.155.209:4432132B<1s🔍 Graph
SESSION-c23a5aed483f…TCP [AFPRS]185.150.99.2:48792172.234.197.23:4433934.0K0.7s🔍 Graph
SESSION-91aca517c733…ICMP172.234.197.23:*116.99.174.160:*5510B15.3s🔍 Graph
SESSION-1b2f3e4993f1…TCP [APS]2.57.122.191:11818172.234.197.23:22285.4K7.4s🔍 Graph
SESSION-c20a05fee3bd…ICMP172.234.197.23:*49.207.40.162:*6612B5.1s🔍 Graph
SESSION-3369eb903017…TCP [AFPRS]46.4.252.37:59854172.234.197.23:4435333.9K0.8s🔍 Graph
SESSION-1399df195f1f…TCP [AFPRS]37.27.162.26:43244172.234.197.23:443229.3K0.5s🔍 Graph
SESSION-fc66087ce285…TCP [S]116.99.174.160:57414172.234.197.23:225370B15.3s🔍 Graph
SESSION-bfb95e6ad43b…TCP [AFPRS]37.27.162.26:43234172.234.197.23:4434434.3K0.8s🔍 Graph
SESSION-99396c002355…ICMP172.234.197.23:*200.46.125.168:*2252B3.0s🔍 Graph
SESSION-5a347e273980…TCP [AFPRS]46.4.252.37:59870172.234.197.23:443218.2K0.5s🔍 Graph
SESSION-e2d59e784556…TCP [APR]67.219.103.9:39884172.234.197.23:4434283B<1s🔍 Graph
SESSION-e1d291b1bb58…TCP [AFPRS]184.171.210.134:55424172.234.197.23:4434334.2K0.2s🔍 Graph
SESSION-e3f30bf8a55e…TCP [FA]97.139.29.134:62896172.234.197.23:4433162B0.0s🔍 Graph
SESSION-c42740c30bd3…TCP [AFPRS]136.243.57.208:39838172.234.197.23:4434634.4K0.8s🔍 Graph
SESSION-e8fbad6d9754…TCP [AFPRS]172.3.50.214:43124172.234.197.23:443228.3K0.2s🔍 Graph
SESSION-8e85f2f3a7c3…TCP [AFPRS]195.154.100.87:37156172.234.197.23:443219.2K0.5s🔍 Graph
SESSION-eae1eddaa755…TCP [APR]172.234.197.23:22118.33.70.70:343422172B0.2s🔍 Graph
SESSION-ad579d0127ed…TCP [FAPS]185.242.226.114:54995172.234.197.23:80101.5K0.2s🔍 Graph
SESSION-66b1039f3032…TCP [FAPR]2.57.121.25:31377172.234.197.23:226656B17.6s🔍 Graph
SESSION-59bc62fc3a6a…TCP [AFPRS]184.171.210.134:55430172.234.197.23:443249.4K0.1s🔍 Graph
SESSION-659d771dab95…TCP [FA]97.139.29.134:51449172.234.197.23:4433162B0.1s🔍 Graph
SESSION-c1d027b17368…UDP172.234.197.23:58868172.232.0.16:532282B<1s🔍 Graph
SESSION-2080b42e290f…TCP [S]49.207.40.162:51267172.234.197.23:226444B5.1s🔍 Graph
SESSION-cecf858d30fa…TCP [AFPRS]172.3.50.214:43108172.234.197.23:4434533.3K0.4s🔍 Graph
SESSION-c63a43740ace…TCP [AFPRS]136.243.57.208:39852172.234.197.23:443219.2K0.6s🔍 Graph
SESSION-199f047d307c…ICMP172.234.197.23:*2.57.121.25:*3338B2.4s🔍 Graph
SESSION-24a5e50d51fe…TCP [AFPRS]185.150.99.2:48808172.234.197.23:443219.2K0.5s🔍 Graph
SESSION-ffee2cbf5733…TCP [APR]172.234.197.23:22103.115.41.16:384722172B0.2s🔍 Graph
SESSION-f87df51ee022…TCP [AFPRS]94.130.10.221:51658172.234.197.23:4434034.0K0.8s🔍 Graph
SESSION-09a85aa93bfb…TCP [APR]172.234.197.23:2245.148.10.151:450182172B0.1s🔍 Graph
SESSION-7820c5046cc6…TCP [AFPRS]51.91.243.64:36118172.234.197.23:4434533.3K0.7s🔍 Graph
SESSION-0fa427f881e1…TCP [AFPRS]65.108.246.230:13942172.234.197.23:4434234.3K0.7s🔍 Graph
SESSION-795fcb5bdf3e…TCP [AFPRS]5.75.182.251:53112172.234.197.23:4433833.9K0.7s🔍 Graph
SESSION-7b9d1137f597…TCP [AFPRS]94.130.10.221:51664172.234.197.23:443229.3K0.6s🔍 Graph
SESSION-c63b498826de…TCP [AFPRS]163.192.126.71:56668172.234.197.23:443238.3K0.1s🔍 Graph
SESSION-ea3a5e2563e5…TCP [FAP]172.234.197.23:22200.46.125.168:393663314B3.1s🔍 Graph
SESSION-e875e434c16c…TCP [AFPRS]88.99.91.59:54640172.234.197.23:4433932.9K0.7s🔍 Graph
SESSION-69f6e1374fe3…TCP [AFPRS]163.192.126.71:56662172.234.197.23:4433933.2K0.2s🔍 Graph
SESSION-d6102738e913…TCP [APS]172.234.197.23:49046172.64.155.209:4431310.5K0.2s🔍 Graph
SESSION-c6e8cad01bd1…TCP [AFPRS]57.128.95.174:39294172.234.197.23:4434434.3K0.6s🔍 Graph
SESSION-bbf87f7c00cf…TCP [AFPRS]51.91.243.64:36124172.234.197.23:443228.2K0.6s🔍 Graph
SESSION-bec90cc862c0…TCP [AP]97.139.29.134:54827172.234.197.23:223599549.6K29.0s🔍 Graph
SESSION-3f84ec5cb28b…TCP [AFPRS]65.108.246.230:39801172.234.197.23:443219.3K0.6s🔍 Graph
SESSION-9c5943d565b4…TCP [AFPRS]5.75.182.251:53122172.234.197.23:443219.2K0.7s🔍 Graph

Artifact: PCAP:OfflineHyperGraphBunble_SocialPost04142026:f89775956a5d115 sessions total

Leave a Reply

Your email address will not be published. Required fields are marked *