标签：#network

This is Part 1 of a 5-part series on Cisco EEM. We start here with the fundamentals and a few working applets, then build toward self-healing networks, automated diagnostics, compliance guardrails, and a complete real-world deployment. Ask ten network engineers what they use EEM for, and nine will say the same thing: "Oh, I have an applet that auto-recovers err-disabled ports." Then they never touch it again. That's a shame, because Embedded Event Manager is one of the most capable tools already sitting inside every Cisco IOS device you own — and almost nobody uses more than 1% of it. It's a full automation engine that lives on the box . No external server. No API gateway. No orchestration platform. Just the router or switch, watching itself, ready to react the instant something happens — even if the WAN is cut, the NMS is down, and it's three in the morning. This series is about using that other 99%. By the end you'll have a toolkit of applets you can deploy and, more importantly, a way of thinking about on-box automation. But we start at the foundation: what EEM actually is, how it's put together, and why "on the box" is a bigger deal than it sounds. What EEM actually is Embedded Event Manager is an event-driven automation framework built into Cisco IOS, IOS-XE, and NX-OS. Strip away the jargon and it's a very simple idea: When something happens, do something about it — automatically, on the device itself. That "something happens" is an event . That "do something" is one or more actions . Bundle an event with its actions and you have an applet — the basic unit of EEM. That's the whole model. The power comes from how many different things can be an event , and how much an action can do. Events EEM can watch for include: A syslog message matching a pattern (an interface flapping, an HSRP state change, a config being saved). An SNMP OID crossing a threshold (CPU over 85%, a power supply going absent, temperature rising). A CLI command being entered (someone typing wr

Modern applications, especially AI agents and distributed systems, need more than logs to understand what is happening. That's why I explored SigNoz, an open-source observability platform built on OpenTelemetry. Setting up SigNoz with Docker was simple. After connecting a sample application, I could view logs, metrics, and traces from a single dashboard within minutes. My favorite feature is distributed tracing. Instead of guessing where requests slow down or fail, SigNoz clearly shows the complete request journey across services, making debugging much easier. The built-in dashboards provide valuable insights into CPU usage, memory, request latency, throughput, and error rates. Having centralized logs alongside metrics and traces saves time by eliminating the need to switch between multiple tools. I also liked the alerting feature, which helps detect issues before they affect users. For AI applications, observability is essential. AI agents make multiple API calls, use tools, and perform complex workflows. SigNoz makes it easier to understand each step, identify failures, measure latency, and optimize performance. Overall, my experience with SigNoz was excellent. It combines logs, metrics, traces, dashboards, and alerts into one intuitive platform. Among all its features, distributed tracing impressed me the most because it provides deep visibility into application behavior and simplifies troubleshooting. I'm excited to use SigNoz in future AI and cloud-native projects.

Quando voce cria um container e depois outro, eles podem nao se enxergar. O motivo quase sempre e a rede. Entender os tipos de rede que o Docker oferece resolve isso de uma vez. Comece listando as redes que ja existem no seu Docker. docker network ls A rede bridge e a rede host vem de fabrica. Nenhuma delas oferece resolucao de nomes entre containers. Para isso voce precisa criar a sua propria rede. docker network create minha-rede Agora os containers que entrarem nessa rede conseguem se comunicar pelo nome do container. docker run -d --name app1 --network minha-rede nginx docker run -d --name app2 --network minha-rede alpine sleep 3600 Teste a comunicacao. docker exec app2 ping app1 -c 2 O ping funciona. O DNS interno do Docker resolve app1 para o IP interno do container. Isso resolve 90% dos problemas de comunicacao. A rede bridge padrao nao tem esse recurso. Crie sua propria rede sempre que precisar que containers se enxerguem. Agora a rede host. Ela elimina o isolamento de rede. O container usa a placa do host diretamente, sem NAT e sem mapeamento de porta. docker run -d --name web-host --network host nginx O nginx fica acessivel em http://localhost:80 direto. Sem -p 80:80. Mas so um container pode usar cada porta, porque a porta e a do host de verdade. Para ambientes com mais de uma maquina, existe a rede overlay. Ela precisa do Docker Swarm ou de um cluster. docker swarm init docker network create -d overlay rede-overlay docker service create --name api --network rede-overlay --replicas 3 nginx Os containers em maquinas diferentes se enxergam pelo nome como se estivessem na mesma maquina. No dia a dia, a rede bridge personalizada resolve quase todo caso de uso. Host e para performance ou casos especificos. Overlay e para quando voce escala para mais de uma maquina. That's all for now. Thanks for reading!

Rosemary: Transparent Network Tunneling Over QUIC (Kernel-Level) Ever SSH into a box and wish you could just use its network without setting up proxy chains or VPNs? Rosemary makes that happen. The server intercepts traffic at the kernel level (no proxy settings, no TUN devices) and tunnels it over encrypted QUIC through a lightweight agent on the remote host. From your laptop, curl , ping , or your browser reach private subnets as if you were there. What you get Kernel-level packet interception, transparent to all your apps TCP, UDP, ICMP, and DNS just work without configuration Route all internet traffic through a chosen agent (egress) SOCKS5 proxies, port forwards, and reverse forwards per agent Multi-hop pivoting through several agents Web dashboard with real-time agent graph Full REST API for automation Works on Linux, Windows, macOS, FreeBSD, and OpenBSD Agents run without root; traffic is AES-256-GCM encrypted over QUIC Quick start # install (requires Go) go install github.com/blue0x1/rosemary/rosemary@latest go install github.com/blue0x1/rosemary/agent@latest # start server (needs sudo for kernel interception) sudo rosemary # deploy agent on remote box ./agent-linux-amd64 -s <server-ip>:2048 -k <your-key> That's it. Open http://server-ip:1024 and you'll see the agent's subnets automatically routed. Set a default egress agent to route all traffic through a jump host: egress agent-1 Now your laptop behaves like it's on the remote network. No proxychains, no ssh -D , no friction. Check the repo blue0x1/rosemary for pre-built binaries, PowerShell agents, and the full API. Use only on systems you own or have permission to test.

Installing Ubuntu Server 24.04 LTS in an offline mode (no LAN cable or WiFi connected) leaves you with an unmanaged network interface which requires manual configuration post-install. The interface enp4s0 is unmanaged by systemd-networkd and also the service itself is disabled. NOTE: This guide applies to Ubuntu server. On Ubuntu desktop you have the NetworkManager service installed and the steps would be different. To fix the problem follow the steps below: Create a Brand New Netplan Configuration File Look into /etc/netplan . You will probably see the dir is empty. This means the installer completely gave up on configuring the network and didn't create any profiles. Create a new file, e.g. vim /etc/netplan/01-netcfg.yaml . Paste the following configuration network : version : 2 renderer : networkd ethernets : enp4s0 : dhcp4 : true This makes the interface managed by networkd instead of the desktop NetworkManager. Fix permissions The new file needs to be readable only by root so fix it's permissions chmod 600 /etc/netplan/01-netcfg.yaml . Enable network service Enable the network service and make it start on boot: systemctl enable systemd-networkd systemctl start systemd-networkd Run netplan Finally, we need to tell Ubuntu to use our new configuration and activate the network netplan generate netplan apply Network should be up! ip a

Understanding the 550 SPF Check Failed Error The "550 SPF Check Failed" error indicates that a receiving mail server rejected an incoming email. This rejection occurs because the sender's domain failed its Sender Policy Framework (SPF) validation. SPF is an email authentication protocol defined in RFC 7208 . SPF helps prevent email spoofing. It allows domain owners to specify which mail servers are authorized to send email on behalf of their domain. Receiving mail servers perform an SPF check by querying the sender's DNS for an SPF TXT record. If the sending server's IP address is not listed in the domain's SPF record, the SPF check fails. The receiving server then rejects the email based on its configured policy, often resulting in a 550 error. This error protects recipients from unauthorized emails and enhances email security. Initial Diagnosis: Identifying the Root Cause Diagnosing an SPF failure requires examining the bounce message and the domain's DNS records. The bounce message often provides specific details about the SPF failure. Look for phrases like "SPF validation failed," "unauthorized sender," or "IP address not permitted." Common reasons for a 550 SPF Check Failed error include: Missing SPF Record: No SPF TXT record exists for the sending domain. Incorrect SPF Syntax: The SPF record contains errors, making it unreadable or invalid. Incomplete SPF Record: The SPF record does not list all legitimate sending IP addresses or hostnames. DNS Lookup Limit Exceeded: The SPF record requires more than 10 DNS lookups, violating RFC 7208. DMARC Policy Enforcement: A DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy ( RFC 7489 ) with p=reject or p=quarantine is in place, enforcing strict SPF failure handling. To begin diagnosis, use our SPF checker to verify your domain's SPF record and its validity. This tool quickly identifies syntax errors and lookup issues. Step-by-Step Troubleshooting and Resolution Resolving SPF failures involves

Understanding DMARC and the 'p=none' Policy DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489, is an email authentication protocol. It builds upon SPF (Sender Policy Framework, RFC 7208) and DKIM (DomainKeys Identified Mail, RFC 6376) to provide domain owners with greater control. DMARC instructs recipient mail servers on how to handle emails that fail authentication and provides reporting on these failures. The p=none policy is often adopted as a preliminary step in DMARC implementation. It instructs recipient servers to take no specific action on emails failing DMARC alignment. Its primary function is to enable the collection of aggregate and forensic reports without impacting email deliverability. Many organizations view p=none as a safe, non-disruptive way to begin their DMARC journey. This initial perception, however, overlooks critical security implications. While it offers visibility, p=none provides no actual enforcement against malicious email. The Critical Security Vulnerability of p=none The fundamental flaw of DMARC p=none lies in its complete lack of enforcement. When a DMARC record is set to p=none , recipient mail servers will not block, quarantine, or reject messages that fail DMARC authentication. This includes emails that spoof your domain directly. Threat actors exploit this vulnerability to conduct phishing, business email compromise (BEC), and brand impersonation attacks. They can send emails appearing to originate from your legitimate domain, knowing that p=none offers no protective barrier. The recipient mail server simply delivers the fraudulent message. This policy effectively leaves your domain unprotected against direct domain spoofing. Despite having a DMARC record, your organization remains susceptible to advanced phishing techniques. The security posture of your email ecosystem is compromised. The Illusion of Insight: Data Without Action DMARC p=none does provide valuable data through its repor

Introduction to DMARC and the p=quarantine Policy DMARC (Domain-based Message Authentication, Reporting, and Conformance), defined in RFC 7489 , is an email authentication protocol. It builds upon SPF and DKIM to provide domain owners with the ability to protect their domain from unauthorized use. DMARC enables senders to specify how receiving mail servers should handle unauthenticated emails originating from their domain. It also provides a mechanism for receiving servers to report back to the domain owner about authentication results. DMARC policies dictate the action receiving mail servers should take when an email fails DMARC authentication. The three primary policies are: p=none : Monitor mode. Receiving servers take no action on failed messages but send reports. This is the initial deployment phase. p=quarantine : Receiving servers should treat failed messages as suspicious. They are typically placed in the recipient's spam folder or flagged for further review. p=reject : Receiving servers should outright reject messages that fail DMARC authentication. This is the strongest enforcement policy. Implementing p=quarantine is a critical step towards full domain protection. It allows domain owners to mitigate spoofing and phishing attempts without immediately blocking legitimate, but misconfigured, email streams. This policy provides a balance between security enforcement and minimizing potential deliverability disruptions. Prerequisites for DMARC p=quarantine Implementation Before deploying a p=quarantine policy, proper configuration of SPF and DKIM is mandatory. DMARC relies on these underlying authentication mechanisms and their alignment with the sending domain. SPF (Sender Policy Framework) SPF, specified in RFC 7208 , allows domain owners to publish a list of authorized sending IP addresses in their DNS. Receiving mail servers check the SPF record to verify if an incoming email originated from an authorized server. An SPF record is a TXT record at the root of

Seven days of flow. Fixed a peer identity binding issue in py-libp2p, automated my Neovim lockfile merges, and added a massive batch of notes on xv6 and Category Theory. 10 commits and a solid PR in the works. TL;DR I managed to hit a perfect seven-day streak this week, balancing some deep-dive p2p networking work with necessary maintenance on my local environment. The highlight was opening a PR in py-libp2p to tighten up how PeerRecords are handled in the Kademlia DHT. On the side, I spent time automating the annoying parts of my Neovim config and dumping a fresh batch of notes into my knowledge base. 10 commits, 204 lines added, and a much cleaner workflow to show for it. What I Built Neovim Configuration & CI I’m a firm believer that your editor should work for you, not the other way around. My nvim repo saw a lot of action this week—9 commits in total—but most of it was under-the-hood maintenance. I’ve been leaning on Lua to keep things snappy, and this week was about ensuring my plugin ecosystem doesn't rot. I pushed several updates to keep plugins at their latest versions, but the real "quality of life" improvement was adding a chore to auto-resolve lazy-lock.json merge conflicts. If you’ve ever worked on your Neovim config across multiple machines, you know the headache of the lockfile drifting. I set up a flow to prioritize incoming changes, which saves me from manually triaging JSON diffs every time I pull from dev . It’s a small tweak, but it removes a recurring friction point in my daily flow. I also spent time cleaning up the root of the config, with about 37 additions and 33 deletions—refactoring is a constant process when you live in your terminal. The Knowledge Base I also put some serious time into main-notes . I’m currently going deep on a few different subjects, and I use this repo as my "second brain." I added 167 lines of new material across 13 files, covering a pretty diverse range of topics: xv6 (the re-implementation of Unix V6), Category Theo

The homelab started flat. One /24, everything on it. My workstation, the NAS, the Proxmox host, and — over time — a growing list of workloads sharing the same broadcast domain because that was the path of least resistance. For a while, that was fine. A homelab running one workload doesn't need segmentation any more than a house needs an office door. Then I stood up an Akash provider. An Akash provider is, in shape, a Kubernetes cluster that accepts inbound tenant workloads from the internet — real deployments, paying for compute, containers I didn't write landing in namespaces on my hardware. The provider itself is documented at github.com/jjozzietech/akash-provider-ops-public — this piece is about the network underneath it. The containerisation posture itself is fine. I trust the isolation model. But trust isn't a network design. And the network at that moment had the tenant workload cluster sitting on the same subnet as my workstation, my NAS, and my Proxmox management interface. That was the moment I stopped thinking of the rack as a home network with extra boxes, and started thinking of it as a small data centre. This piece is the network design that came out of that shift. I'll cover the layout, the rules that hold it together, and the Nexus and Proxmox configs that anchor it — with the specifics of my own deployment sanitised. It's not a step-by-step replication guide. It's the design pattern, with enough of the shape to be useful and enough restraint to not double as a recon document for my own rack. // the original design The flat layout looked like this: home lan — 192.168.1.0/24 opnsense (perimeter) cisco nexus (dumb L2 switching) proxmox host workload VMs (all on the same subnet) What it got right: zero routing complexity, everything reachable from everywhere, fast to stand up. If you're running one project on a homelab, this is the correct design. Don't over-engineer it. What stopped working, as soon as the second project landed on the rack, was that the

If you've ever tried to build a simple command/telemetry protocol between a PC and a fleet of SDR receivers, sensors, or embedded devices, you know the usual options aren't great: Roll your own binary format — fast, but you end up writing and maintaining custom serialization code for every device type, and debugging mismatched structs across machines is painful. Protobuf / FlatBuffers — robust, but require you to define your message layout in a schema file upfront, run a code generator as part of your build, and commit to a fixed structure. Adding a new device type or a new parameter means editing the schema, regenerating, recompiling everything. JSON over the wire — easy to debug, but heavy for anything real-time or bandwidth-constrained. I ran into this while working on a multi-SDR receiver system and ended up writing MessageFrame — a small C++17 library that lets you build structured messages dynamically, without any schema files or code generation. The basic idea Instead of defining a struct for each device type, you address each parameter with two strings — a device name and a parameter name — and the library handles the rest: // One message, multiple devices, assembled at runtime msgframe :: MessageFrame msg ( MSG_TELEMETRY , TYPE_PERIODIC , src = 1 , tgt = 2 ); msg . add ( "sdr_1" , "rx_gain" , VALUE ( 30.0 )); msg . add ( "sdr_1" , "center_freq" , VALUE ( 915'000'000.0 )); msg . add ( "sdr_1" , "sample_rate" , VALUE ( 2'000'000.0 )); msg . add ( "sdr_2" , "rx_gain" , VALUE ( 25.0 )); msg . add ( "sdr_2" , "lock_status" , VALUE ( true )); msg . add ( "psu_1" , "voltage" , VALUE ( 12.04 )); msg . add ( "psu_1" , "temp_c" , VALUE ( 47.3 )); // Attach raw IQ data alongside the parameters std :: vector < uint8_t > iq_buffer = { 0x01 , 0x02 , 0x03 , 0x04 }; msg . add_attachment ( "raw_iq" , std :: move ( iq_buffer )); // Serialize into a buffer, send over whatever transport you use std :: vector < uint8_t > out ; msg . serialize ( out ); send_udp ( out . data (),

I connected one client to a blocking TCP server and held the socket open without sending a single byte. Then I connected a second client and sent it a line of text. The second client sat there for 1.51 seconds with no reply. It got its echo back one millisecond after I closed the first connection. That 1.51 seconds is the reason the other six versions of this server exist. Last week I wrote up why I rebuilt this server seven times : framework knowledge resets every few years, the layer underneath it compounds. That piece stayed at the level of outcomes. This one goes the other way, down into the code and the numbers. The claims that matter here are the kind you can read a hundred times without being able to derive them. "select is O(n)." "epoll only hands you the ready fds." I had read both for years. I wanted to make my own machine say them out loud. The target the whole exercise is built around is Dan Kegel's old C10K problem : how do you serve ten thousand clients at once on one server? Each of the seven versions hits a wall, and the wall is what names the next one. The whole thing is one echo server written seven times, no libraries beyond libc, on GitHub . Every number below is from running it on macOS (Apple clang 21, darwin 25.4) on 2026-06-29. The binaries are built with AddressSanitizer and UBSan on, so read the absolute microseconds loosely. The structure is what holds. Phase 01: blocking, and the 1.5 second stall The first server is the one everybody writes first. Accept a connection, talk to it, close it, accept the next. for (;;) { int client_fd = accept ( server_fd , NULL , NULL ); if ( client_fd == - 1 ) { perror ( "accept" ); continue ; } handle_client ( client_fd ); close ( client_fd ); } handle_client loops on read until the client hangs up. Both accept and read block: when there is nothing to do, the thread sleeps in the kernel. That is good for idle cost and fatal for everything else. While the server is parked in read waiting on client A, client

On Sunday night, the sold-out 2026 AI Engineer World's Fair kicked off its orientation at Moscone...

Monday’s final presentation was perhaps the most unusual one of the day in that it focused more on...

By RUGERO Tesla ( @404Saint ). There is a persistent illusion in Industrial Control Systems (ICS) security research: that high-level libraries, abstraction frameworks, or protocol tooling give you a real understanding of Operational Technology (OT) behavior. They don’t. They hide the architecture. Determined to understand what actually happens when a Programmable Logic Controller (PLC) receives a control-plane command, I built an EtherNet/IP and Common Industrial Protocol (CIP) sandbox from scratch. No Scapy. No protocol wrappers. Just raw sockets, a Linux loopback interface, a cpppo simulator, and a passive monitoring tool ( enip_monitor.py ) capturing traffic in real time. It looked clean on paper. Then I reached the application layer. And things stopped behaving like theory. The Reality of the “Industrial Abstraction Layer” If you come from Modbus or traditional IT networking, you’re used to linear memory spaces—fixed registers, predictable offsets, and flat addressing. EtherNet/IP and CIP discard that model entirely. Instead, they introduce a structured object system wrapped inside multiple encapsulation layers: +-----------------------------------------------------------+ | EtherNet/IP Encapsulation Header (24 bytes) | | → Session control, commands (0x0065, 0x006F) | +-----------------------------------------------------------+ | Common Packet Format (CPF) | | → Routing, addressing, and transport segmentation | +-----------------------------------------------------------+ | CIP Application Layer | | → Service codes (0x4C, 0x4D, 0x10, etc.) | +-----------------------------------------------------------+ To communicate with a PLC at the wire level, your code must: Establish a session using RegisterSession (0x0065) Wrap all subsequent requests in SendRRData (0x006F) Encode routing information inside CPF structures Construct symbolic or logical paths for the CIP Message Router Ensure strict byte alignment across nested payload layers A single mistake in any layer b

Research Context "In advanced network observability, understanding the default behavior of various operating systems is vital for traffic profiling. This article explores the structural differences in ICMP Echo Requests across different OS environments and analyzes how 'Traffic Mimicry' can be used to evaluate the accuracy of Network Intrusion Detection Systems (NIDS)." 1. The Anatomy of an ICMP Signature A standard ICMP Echo Request is not just a simple signal; it carries a specific "fingerprint" based on the operating system that generated it. These fingerprints consist of: Total Packet Size TTL (Time to Live) values Default Payload Content 2. Cross-Platform Discrepancies (Linux vs. Windows) When a system sends a "ping," the default data size ($D$) and the total packet length ($L$) vary significantly between architectures. Feature Linux (Typical) Windows (Typical) Data Size ($D$) 56 Bytes 32 Bytes ICMP Header ($H$) 8 Bytes 8 Bytes Total ICMP Length ($L$) 64 Bytes 40 Bytes Default Payload Timestamp + Data abcdefg... The Linux Signature In most Linux distributions, the ping utility sends 56 bytes of data. When combined with the 8-byte ICMP header, it totals 64 bytes. A key characteristic of Linux ICMP traffic is that the first few bytes of the payload are often occupied by a high-resolution timestamp, used to calculate RTT (Round Trip Time) with microsecond precision. The Windows Signature Windows systems default to a 32-byte data payload. The payload content is static and follows a predictable alphabetical sequence: abcdefghijklmnopqrstuvwabcdefghi. This static nature makes Windows ICMP traffic easily identifiable during deep packet inspection (DPI). 3. The Concept of Traffic Mimicry Traffic Mimicry is a research method used to test the resilience of network filters. By aligning custom communication protocols with the default signatures of a specific OS, researchers can evaluate whether a security appliance is biased toward certain traffic patterns. For example, wh

Move would test whether group can turn ambition into a mass-market phone business.

You type www.google.com into your browser and hit Enter. The page loads in under a second. But stop and think about what just happened. Your browser didn't know where Google lives on the internet. It had to ask. And in that fraction of a second, a surprisingly elegant chain of lookups took place behind the scenes. That system is called DNS — the Domain Name System. Think of it as the internet's phonebook: it translates human-friendly names like www.google.com into machine-friendly IP addresses like 142.250.80.46 . Without it, you'd have to memorise numbers to visit any website. Let's walk through exactly what happens, step by step. Step 1: You Type a URL — But What Does It Mean? When you type www.bing.com , you're entering a domain name . Domain names have a structure — and reading them right-to-left tells you a lot: www . bing . com │ │ │ │ │ └── Top-Level Domain (TLD): category or country │ └──────── Second-Level Domain (SLD): the brand/org name └─────────────── Subdomain: a section of the site (optional) Some real examples: Domain TLD SLD Subdomain www.bing.com .com bing www news.bbc.co.uk .uk bbc news docs.github.com .com github docs TLDs indicate the type or origin of a site — .com for commercial, .edu for education, .in for India, and so on. Step 2: Your Browser Checks Locally First Before going anywhere on the internet, your browser does a quick local check — two of them, actually. 1. Browser cache Modern browsers cache DNS results from previous lookups. If you visited bing.com five minutes ago, the browser already knows its IP and skips the entire lookup process. 2. The hosts file Your operating system has a plain text file that maps domain names to IPs manually. On most systems it lives at: Windows: C:\Windows\System32\drivers\etc\hosts Mac/Linux: /etc/hosts It looks like this: 127 . 0 . 0 . 1 localhost 192 . 168 . 1 . 10 mydevserver . local Developers use this all the time for local testing — mapping a production domain name to a local IP to test before go

Environment And Situation Control room of an apartment Number of installed product : 3 (PC-based NVR, dual-LAN supported) Remote support : X (I actually went to the site and diagnosed) Reported Issue In viewer, when user changes play speed while playing back the recorded data, it randomly plays the data in hyper speed(almost 30x~60x) For example: 4x play means 4 seconds in video per a second. But in the site, it played 30~60 seconds per a seconds, showing the video stutturing. Diagnosis Checked the overall environment. System(CPU / RAM usage), network environment(bandwidth), resoulution, stream configurations, etc. -> Nothing suspicious. Some of the installed cameras had unusual fps and gop values Normally, fps and gop values are set to be equal(for exmaple, if fps is 30 then gop is also 30 so that iframe can appear every second) But the cameras' set up values were fps 15, gop 60(iframe per 4 seconds) Assumption Somehow the viewer keeps failing to find iframe to play. And it's maybe because iframe appears with a long gap. Quick note: iframe is kind of a key-frame. Since the viewer starts decoding from an iframe, it's necessary when it comes to playback. What I Tried Set all the cameras' gop value to 15(same as fps) Result Ran a test with data before changing the gop values and after. During interval before changing the gop, the issue occurred almost every time I tried. But after chaning the gop, the issue no longer occurred. Concolusion The issue was triggered by large GOP value (GOP 60 with FPS 15). With only one iframe every four seconds, the viewer sometimes failed to find an appropriate iframe after changing the playback speed, causing abnormal playback behavior. According to the viewer developer, this is likely related to the viewer's iframe searching logic, which is still under investigation. Keep This In Mind Check camera settings(especially gop and fps) first when it comes to playback issue. Always check before/after data to confirm assumption.