标签：#network

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-07/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols as logic — inputs, state, and branches — rather than as configuration examples. Every module points at one real Python file and asks you to read it the way you'd read any other code: what comes in, what mutates, where does control leave early. The source lives at github.com/pathvector-studio/protocol-in-code . Note: If you're newer to this and want to run things before you read things, start with Protocol Lab — the hands-on companion series that builds the muscle memory this one assumes. The question How does local import policy change or reject a path before best-path selection runs? That's the whole module in one line, and it hides a claim worth being suspicious of. Best-path selection in BGP is the famous part — the ordered tiebreaker list everyone half-remembers: highest weight, highest local_pref , shortest AS path, and so on. It's easy to treat that comparison as the decision point, as if routes arrive from peers and get ranked. They don't arrive and get ranked. They arrive, get rewritten , and then get ranked. Import policy is a function that runs between the wire and the comparison, and it has two powers: it can change the values the comparison reads, and it can make the candidate not exist at all. Which means the interesting question isn't "who won best-path" but "what did best-path actually receive." Read the code The file is src/protocol_in_code/bgp/import_policy.py . It's short enough to hold in your head all at once, which is the point — the shape is the lesson. Start with the policy object: @dataclass ( frozen = True ) class ImportPolicy : local_pref_override : int | None = None weight : int = 0 reject_next_hops : tuple [ str , ...] = () reject_invalid : bool = False Four knobs, and notice they're not four of the same thing. Two of them ( local_pref_overri

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-05/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols not as configuration examples but as logic with inputs, state, and branches — actual code you can read and run. The whole series lives here: github.com/pathvector-studio/protocol-in-code . If you're newer to this material and want a more hands-on, guided on-ramp first, start with the companion Protocol Lab series and come back. Today's module is from the BGP track, Session 05. The source file is src/protocol_in_code/bgp/policy.py , and it builds directly on the origin-validation logic from Session 04. The question to keep in your head Here's the one thing to turn over as you read: What happens after origin validation returns valid , invalid , or not_found — and why does the result still need routing policy before anything happens to the route? There's a piece of folk knowledge that says "RPKI invalid means the router rejects the route." It's the kind of statement that sounds like a rule of the protocol. It isn't. It's one possible policy decision built on top of a validation result . The whole point of this session is to separate those two things in your head, and the code makes the seam impossible to miss. Two layers, not one Validation answers a factual question: does this route's origin AS match what the ROAs say it should be? That's Session 04's job, and its output is a ValidationState . Policy answers a completely different question: given that fact, what do we do ? Drop the route? Keep it but make it less preferred? Accept it normally? That's a local decision — different operators configure it differently, and the same validation result can lead to different actions on different routers. The file models the second layer with three small pieces. First, the set of actions the router can take: class PolicyAction ( str , Enum ): ACCEPT = " accept " DEPRIORITIZE = " de

Originally published at https://blog.pathvector.dev/protocol-in-code-bgp-04/ — part of the free Protocol Lab series. This post is part of Protocol in Code , a free series that reads network protocols as logic — inputs, state, and branches — rather than as configuration examples. The full source, walkthroughs, and site lessons live in the repo: pathvector-studio/protocol-in-code . If you're newer to this and want to build the protocols hands-on before dissecting them, start with the companion Protocol Lab series instead. Today we're on the BGP track, session 04, reading a single small file: src/protocol_in_code/bgp/validation.py . It's about 40 lines. The idea inside it is one that trips up a lot of engineers who've been running BGP for years. The question to keep in your head BGP's best path selection already ran. It compared local preference, AS_PATH length, MED, and the rest of the tiebreak ladder, and it picked a winner. So here's the question this module wants you turning over: Core question: How do we decide whether the origin AS is authorized — even after BGP has already selected this route as the best path? The trap is the sentence "it was the best path, so it must be fine." Best and authorized are two different words, and in the code they are two different decisions made by two different pieces of data. Best path selection asks which of these routes do I prefer? Origin validation asks is the AS at the end of this path actually allowed to originate this prefix? A route can win selection and still be a hijack. RPKI origin validation is the mechanism that answers the second question, and the file we're reading is a toy model of exactly that. Two kinds of information The first thing to read isn't a function — it's the two dataclasses, because the whole session is really about keeping them apart. @dataclass ( frozen = True ) class BGPRoute : prefix : str origin_as : int @dataclass ( frozen = True ) class VRP : prefix : str max_length : int origin_as : int BGPRout

Every five minutes or so, my entire Windows machine would drop off the network for a few seconds — not just WSL, the whole host. Browser tabs would stall, calls would drop, and it only happened while WSL2 was running. This is the story of finding that, plus the WSL memory-tuning landmines I hit right alongside it. The flapping The symptom was a host-wide network blip on a short, regular interval, correlated tightly with WSL2 being up. The cause: WSL2's default networking mode creates a virtual NAT switch on the Windows side, and on this machine that virtual switch was intermittently conflicting with the real network adapter — enough to cause the whole host to briefly renegotiate its connection. The fix was switching WSL2's networking mode entirely, via .wslconfig (on Windows, not inside the Linux filesystem): [wsl2] networkingMode = mirrored dnsTunneling = true autoProxy = true Mirrored networking makes the WSL2 interface share the host's actual network identity instead of sitting behind a separate virtual NAT switch. You can confirm it actually took effect (rather than just trusting the config file) by checking, from inside WSL after a full restart, that its network interface holds the same IP as the Windows host, that the default route points at the real LAN gateway rather than a private NAT range, and that loopback carries mirrored mode's marker address rather than a 172.x NAT address. If any of those don't match, the setting isn't actually active yet. Worth noting: this requires a reasonably recent WSL version and Windows build. If you're on an older one, mirrored mode may not be available at all. The memory landmines, found the hard way Separately — and this had actually caused full VM crashes, not just hangs, at one point — I'd been carrying a few .wslconfig settings that looked reasonable and were each, individually, a documented source of instability: An explicit kernelCommandLine override. Resizing swap past a few GB, which forces WSL to rebuild its virtual

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

"Any potential damage will be assessed when it is safe to do so."

Ethereal Bytecode for the Network: Unlocking XDP's Magic! Hey there, fellow tech enthusiasts! Ever felt like the traditional networking stack in your Linux kernel was a bit… sluggish? Like it was taking the scenic route when you needed it to be a supersonic jet? Well, let me introduce you to a superhero that swoops in and turbocharges your network packet processing: eBPF, specifically in the context of XDP (eXpress Data Path). Forget the days of wrestling with complex kernel modules or praying for better hardware offload. eBPF and XDP offer a revolutionary, in-kernel, safe, and incredibly efficient way to program packet processing at the very edge of your network interface. Think of it as giving your network card a tiny, super-smart brain, capable of making lightning-fast decisions before the packet even bothers the main kernel stack. Pretty cool, right? So, buckle up as we dive deep into the wonderful world of XDP and eBPF, demystifying its power and showing you why it's becoming the darling of modern networking. 1. The "What's the Big Deal?" Section: Introduction to XDP & eBPF Imagine a bustling highway (your network). Traditional networking is like having every car stop at a toll booth, get inspected, and then directed by a central traffic controller. This works, but it can get congested. XDP, on the other hand, is like having intelligent on-ramps where some cars can be instantly identified, rerouted, or even rejected before they even hit the main highway. eBPF (extended Berkeley Packet Filter) is the technology that makes this possible. It's a powerful, sandboxed virtual machine that runs within the Linux kernel. Unlike traditional kernel modules, which can potentially crash your entire system if written incorrectly, eBPF programs are rigorously verified by the kernel for safety and correctness before they are allowed to execute. This means you get the power of kernel-level access without the existential dread of a kernel panic. XDP (eXpress Data Path) leverages

What We Learned Building a Location-Aware Contact Management App Most contact apps are built like digital phonebooks. They store a name, phone number, email, maybe a company name, and then leave the user to remember everything else. That works when someone has 50 people saved. It starts breaking when someone has hundreds or thousands of professional connections from events, client meetings, referrals, business cards, conferences, online communities, and local networking groups. The hard part is not storing people. The hard part is helping users find the right person at the right time. While building a location-aware contact management app, we learned that contact data becomes far more useful when it is connected to context: where someone is, how the user met them, what they discussed, what industry they belong to, and why the relationship matters. Here are some product, UX, and privacy lessons we learned along the way. 1. A contact list is not the same as a usable network A normal contact list answers one basic question: “Do I have this person’s number?” But professionals usually need better questions answered: Who do I know in this city? Who did I meet at that event? Which industry contacts are nearby? Who should I follow up with before visiting this area? Who was that consultant I met last month? Which contacts are important but easy to forget? This is where the product problem becomes interesting. A user may technically have the contact, but still fail to use the relationship because the contact is buried inside a long list. So the first learning was simple: Saving contact details is not enough. The app needs to help users retrieve useful relationships when the context matters. That changed how we thought about the product. We were not just designing a place to store people. We were designing a system to make saved professional relationships easier to act on. 2. Location context changes the experience Most contact managers are list-first. You search by name, comp

I'm the developer of DeviceShelf, a local-first network scanner for desktop, mobile and a headless server edition. Until this week the iOS app only existed on TestFlight. Apple has now approved version 1.3.0, so for the first time you can get it straight from the App Store: DeviceShelf on the App Store . What the app does on a phone The iOS app is not a companion viewer. It runs the same scanning engine as the desktop version: it scans the network you're on, identifies devices (vendor, type, OS fingerprint), shows open ports per device, builds a security report, and raises presence alerts when devices appear or drop off. You can export and share results from the phone. The multicast entitlement iOS restricts multicast traffic for ordinary apps, and SSDP/UPnP discovery depends on it. Apple grants the multicast entitlement on request, and DeviceShelf's App Store build has it. In practice, UPnP/SSDP devices show up in scans on the phone the same way they do on desktop. Licensing The download is free and comes with a trial. Full features unlock in one of two ways: activate a DeviceShelf license, which covers desktop, mobile and the server edition with a single purchase, or use the in-app purchase upgrade on iOS. Pricing is on the website if you want the details. Local-first, on mobile too Scans stay on the device. There is no cloud account, and the AI-assisted device identification is bring-your-own-key; no key is bundled or required. The app is still young, and a phone is an unforgiving place for a network scanner. If it mislabels a device on your network or misses one entirely, I'd genuinely like to hear about it. Website: deviceshelf.app

local + echo = locho Sometimes you don't need access to a machine. You don't need a shell. You...

Introduction Linux is the backbone of modern infrastructure. From cloud servers and firewalls to SIEM platforms and security tools, Linux runs silently behind most enterprise environments. For a Security Operations Center (SOC) analyst, understanding Linux is not optional — it is a core skill. One of the most critical security mechanisms in Linux is its file permission and ownership model. Attackers abuse permissions to execute malware, hide persistence, escalate privileges, and erase evidence. SOC analysts rely on permission analysis to detect anomalies, investigate incidents, and build accurate timelines. Become a Medium member This article covers Linux File Permissions and Ownership in deep detail from a SOC analyst’s perspective. It is designed to take you from absolute beginner to security-aware professional, with real-world examples, attack scenarios, and investigation insights. Why Linux File Permissions Matter in SOC In SOC operations, analysts constantly deal with: Authentication logs System logs Application logs Scripts and binaries Configuration files Evidence files during incident response Every one of these objects is protected by Linux permissions. From a SOC perspective: Incorrect permissions = security risk Permission changes = potential indicator of compromise Executable permissions = possible malware Ownership changes = possible log tampering Understanding permissions allows SOC analysts to: Detect unauthorized access Identify privilege escalation Spot malware execution Preserve forensic evidence Reconstruct attacker activity Understanding Linux File Permission Basics Linux follows a Discretionary Access Control (DAC) model. This means: The owner of a file controls who can access it Permissions define what actions are allowed Every file and directory in Linux has: A type Permissions An owner (user) A group These attributes decide: Who can read the file Who can modify it Who can execute it Viewing Permissions Using ls -l The most common command to i

Week 0 of my DevOps Micro Internship was about the foundations—the parts of the internet you use every day without thinking about them. The exercise that made it click was a simple scenario: a friend launches an online bookstore called EpicReads, hosted on a server in Finland, and asks how people anywhere in the world can open it. The answer is a short chain of technologies working together. The Chain of Technologies Packet Switching: When someone opens the site, their request does not travel as one big lump. Packet switching breaks the data into small packets that each take the best available path across the network and get reassembled at the other end. This is what keeps the internet fast and resilient even across continents. IP Addresses & TCP/IP: Every device on the way has a unique IP address, like a postal address, so the user's computer and the Finland server can actually find each other. The TCP/IP suite runs the conversation: IP handles addressing and routing, while TCP makes sure the packets arrive complete and in the right order, asking again for anything that went missing. HTTP & HTTPS: On top of that sits HTTP and HTTPS, which define how the browser and server actually exchange the web pages. HTTPS adds encryption, so a customer's details and payment stay private. DNS: The last piece is DNS. Nobody wants to type an IP address, so DNS acts as the internet's phonebook, translating epicreads.com into the server's IP. To point a domain at an IPv4 address, you use an A record . The Biggest Takeaway The biggest lesson for me was not any single term. It was seeing how these layers hand off to each other so cleanly that the whole thing feels instant to a user. Understanding that chain is the groundwork for everything else in DevOps, because once you know how a request really travels, troubleshooting stops being guesswork. P.S. This post is part of the DevOps Micro Internship with Agentic AI Cohort 3 by Pravin Mishra. You can begin your DevOps journey by joining

Originally published at https://blog.pathvector.dev/protocol-lab-trace-19/ — part of the free Protocol Lab series. This post is part of Protocol Lab , a free, hands-on series for learning networking protocols by building and breaking them in a container lab. All the lab material — topologies, configs, and scripts — lives in the repo: github.com/pathvector-studio/protocol-lab . Every IP packet carries a TTL (time to live) that each router decrements by one. When it reaches zero, the router drops the packet and sends back an ICMP time-exceeded message. traceroute turns this rule into a map: send probes with TTL 1, 2, 3, … and each dying probe reveals the router at that distance. Reading guide: rfc-notes/traceroute-ttl.md Prerequisite: TCP Lab 07: Handshake and Teardown (reading captures) Expected time: 40–55 minutes. The Goal This lab builds a real multi-hop path and shows the mechanism: client → r1 → r2 → server , with two Linux routers in the middle, traceroute from the client lists each hop: 10.0.1.2 (r1), 10.0.2.2 (r2), 10.0.3.2 (server), a packet capture shows the ICMP time-exceeded replies (from r1 for TTL 1, from r2 for TTL 2) that traceroute is built on. By the end, you should be able to explain this table: Probe TTL Dies at Reply 1 r1 ( 10.0.1.2 ) ICMP time-exceeded from r1 2 r2 ( 10.0.2.2 ) ICMP time-exceeded from r2 3 server ( 10.0.3.2 ) reaches the destination What You Will Learn What the IP TTL field is for (loop protection) and how routers decrement it. What an ICMP time-exceeded message is and who sends it. How traceroute uses increasing TTLs to discover each hop. Why the hops appear in order, and why the last hop is the destination itself. The difference between forwarding (routers) and being an endpoint. This lab does not cover: UDP vs ICMP vs TCP traceroute probe types in depth (we use ICMP mode). Load-balanced paths (ECMP) where hops can vary between probes. Why some hops show * * * (rate limiting or filtered ICMP) in the real internet. Where to Rea

Today I'm excited to launch RegionCheck , a tool for testing, monitoring, and debugging endpoints from cloud regions around the world. The idea is simple - test an endpoint's DNS and HTTP connectivity and response from a defined set of cloud regions. Whether you're troubleshooting an API, validating a deployment, checking DNS propagation, or investigating latency, seeing the results from multiple cloud regions can quickly reveal issues that aren't obvious from your own machine. What is RegionCheck? RegionCheck lets you run endpoint checks from AWS, Azure, and Google Cloud regions without provisioning infrastructure or maintaining test instances. Current capabilities include: HTTP endpoint testing DNS lookups TLS certificate validation Continuous monitoring with alerts Side-by-side comparison across cloud providers and regions Shareable result pages for collaboration API/MCP access for automation and agents Why I built it When debugging production issues, I often wanted to answer questions like: Is DNS returning the same result everywhere? Or is geo-DNS returning the results intended? Is TLS certificate propagation for my CDN working as intended? Is one region significantly slower than another? Is my CDN caching working as expected? Are my geo-HTTP redirects working as intended? (For some interesting examples try www.yahoo.com and www.cnn.com in non-US regions) There are many tools that exist that provide these answers, but nothing that answers all of these questions in one place. That's what RegionCheck aims to provide. Who it's for RegionCheck is designed for engineers who work with cloud infrastructure, including: DevOps engineers Site Reliability Engineers (SREs) Platform engineers Backend developers Anyone who likes to take a peek at backend infrastructure Try it out RegionCheck is available at https://regioncheck.io You can run free checks directly from the website; or create an account to access monitoring, alerting, the API, and additional features. I'd love

I have been working on building a private, secure network accessible from anywhere. The goal was to connect my mobile phone and my local development laptop using a WireGuard VPN , hosting the central gateway on a free-tier Google Cloud Platform (GCP) e2-micro instance. I wanted to access my self-hosted services, specifically my Docker-hosted Open WebUI , running on my local home Wi-Fi connected laptop, directly from my phone using mobile data. It sounded straightforward. But if you read my other from scratch journeys, you might have already guessed, it was not. The Setup My architectural plan was a simple hub-and-spoke topology: The Hub: GCP VM ( 10.66.66.1 ) with IPv4 forwarding enabled. Spoke 1 (My Phone): 10.66.66.2 Spoke 2 (My Laptop): 10.66.66.3 I wrote my server configurations, enabled IP forwarding ( net.ipv4.ip_forward=1 ), wrote the iptables rules to allow forwarding between peers, and started the interfaces. Then came the moment of truth. I tried to bring up the tunnel. Absolute silence. No packet moving from anywhere. Hurdle 1: The Classic Cloud NAT Trap (Internal vs. Public IP) Before I could even worry about routing packets between my phone and laptop, I couldn't even get them to handshake with the GCP server. Like many of us do when working inside a VM, I had run ip addr on the GCP instance to grab its IP address for my client configurations. I set up the WireGuard peers to point to this IP. Nothing connected. The Culprit: GCP (and AWS) operates on a 1:1 NAT mapping. The virtual network interface inside your VM only sees and binds to a private, internal cloud IP (e.g., 10.128.0.x ). The public IP assigned to your instance lives outside the VM at the VPC gateway level. By putting the internal IP into my client configs, my phone and laptop were trying to connect to a private address that didn't exist on their local networks. The Fix: I had to swap the internal IP in the client configurations with the GCP Ephemeral/Static External IP . Once the handshake

You've probably registered a domain with Route53 or another popular registrar. You pick something...

What Is My IP Address? IPv4 vs IPv6 Explained for Developers If you've ever debugged a CORS error, set up an IP allowlist, or wondered why req.ip returned something weird in your Express logs, you've run into the same question from a different angle: what actually is an IP address, and which one is "mine"? fastestchecker.com This post breaks down IPv4 vs IPv6, public vs private IPs, and how to reliably detect a user's IP address in your own code — plus a fast way to check yours right now. fastestchecker.com TL;DR IPv4 addresses look like 192.168.1.1 — four numbers, 0-255, separated by dots. There are about 4.3 billion of them, and we've run out. IPv6 addresses look like 2001:0db8:85a3::8a2e:0370:7334 — a much larger address space designed to replace IPv4. Your device usually has a private IP (local network) and shares a public IP (internet-facing) with everyone else on your router. You can check your current public IP instantly with a tool like FastestChecker's IP Checker — useful for confirming what your server or API actually sees. > IPv4 vs IPv6 : What's the Actual Difference IPv4 IPv4 has been the backbone of the internet since the 1980s. It's a 32-bit address, which caps the total number of unique addresses at roughly 4.3 billion. Given how many devices are online today, that pool has been effectively exhausted for years — which is why NAT (Network Address Translation) exists: it lets an entire household or office share one public IPv4 address. Example IPv4: 203.0.113.42 IPv6 IPv6 uses 128-bit addresses, which gives it an address space so large it's effectively unlimited for practical purposes (2^128 addresses). It was designed specifically to solve IPv4 exhaustion, and adoption has been climbing steadily — most major cloud providers and mobile carriers support it by default now. ** Example IPv6:** 2001:0db8:85a3:0000:0000:8a2e:0370:7334 Quick Comparison IPv4IPv6Address length32-bit128-bitFormatDotted decimal (192.168.1.1)Hexadecimal, colon-separatedTotal addre

The Iranian government exploited well-known flaws in cellphone networks to locate and then strike U.S. military personnel in the build-up and beginning of the war.

Meta recently open-sourced Brain2Qwerty v2, a noninvasive Brain–Computer Interface (BCI) that can decode sentences from thoughts using electroencephalography (EEG) or magnetoencephalography (MEG) signals from the brain. In evaluations, the system achieved a word accuracy rate 61% on average, compared to 8% for other non-invasive methods. By Anthony Alford