# TCP/IP Published articles for TCP/IP. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Wireshark: analiza tráfico de red visualmente DevFeed: [Wireshark: analiza tráfico de red visualmente]() Original publisher: [Read original article]() Author: Antonio Pérez Published: 2026-08-02T00:00:00Z Content type: tutorial Language: es Sources: [tengoping.com]() Topics: [TCP/IP](), [Linux](), [Ethernet](), [Debian](), [Ubuntu](), [Command-line interface](), [interfaces](), [macOS](), [Windows]() Tags: [debian](), [ethernet](), [interfaces](), [linux](), [macos](), [tcp-ip](), [terminal](), [ubuntu](), [ubuntu-24-04](), [windows]() ### AI overview A practical guide to Wireshark covering installation, packet capture without running the graphical application as root, display filters, protocol-layer inspection, and TCP flow tracking. It includes real capture examples and discusses the security implications of granting capture permissions. ### Source excerpt Guía práctica de Wireshark: instalación, captura sin root, filtros de visualización, inspección de capas y seguimiento de flujos TCP con ejemplos reales. ## Rust smoltcp as an alternative TCP/IP stack for ESP-IDF DevFeed: [Rust smoltcp as an alternative TCP/IP stack for ESP-IDF]() Original publisher: [Read original article]() Author: John Lee Published: 2026-06-19T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [Rust](), [networking](), [ESP32](), [ESP32-P4](), [HTTP](), [MQTT]() Tags: [blog](), [c](), [concurrency](), [esp-idf](), [esp32-p4](), [ethernet](), [firmware](), [http](), [http-server](), [ipv4](), [ipv6](), [lwip](), [mqtt](), [networking](), [rust](), [smoltcp](), [tcp-ip](), [tls]() ### AI overview This article explains how to run the Rust smoltcp TCP/IP stack as an alternative IPv4/IPv6 data plane under ESP-IDF. It describes a GNU linker --wrap shim that preserves compatibility with ESP-IDF networking components such as esp_http_server, esp-tls and esp-mqtt, along with the single-task poll architecture, measured ESP32-P4 throughput, and known limitations. ### Source excerpt A set of ESP-IDF components that run the Rust smoltcp stack as the IPv4/IPv6 data plane, while keeping esp_http_server, esp-tls and esp-mqtt working without source changes. This article explains the linker -wrap shim that makes it compatible, the single-task poll architecture, the throughput I measured on an ESP32-P4 (91.15 Mbit/s on a 100 Mbit link), and the limitations to be aware of. ## Putting the Tech in Fintech: How We Use FIX to Execute Trades at Scale DevFeed: [Putting the Tech in Fintech: How We Use FIX to Execute Trades at Scale]() Original publisher: [Read original article]() Author: Grace Sun Published: 2026-04-22T00:27:03Z Content type: article Language: en Sources: [Wealthfront]() Topics: [distributed-systems](), [networking](), [Transactions](), [Back end](), [IP routing](), [TCP/IP]() Tags: [architecture](), [backend](), [distributed](), [financial](), [infrastructure](), [networking](), [route](), [scale](), [systems](), [tcp-ip](), [tech](), [technology](), [trading](), [transactions](), [wealthfront-engineering]() ### AI overview Wealthfront explains the distributed-systems infrastructure it uses to route and execute large volumes of stock trades. The article describes broker networking, IP routing, the FIX protocol, and the application layers supporting automated, low-latency trade execution. ### Source excerpt At Wealthfront, the "tech" in financial technology isn't just a buzzword--it's the foundation of everything we build. Beneath the intuitive frontend our clients interact with lies a complex ecosystem of distributed systems. One of the most critical pieces of that backend architecture is the engine that enables us to route massive volumes of trades efficiently. ... Read more ## Testing IP Multicast with netlab DevFeed: [Testing IP Multicast with netlab]() Original publisher: [Read original article]() Published: 2025-11-26T06:56:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Routing (disambiguation)](), [Testing](), [GitHub]() Tags: [github](), [ip](), [multicast](), [netlab](), [permission](), [routing](), [tcp-ip](), [testing](), [volume](), [worth-reading]() ### AI overview The article highlights Aleksandr Albin's nearly 20-router lab topology for practicing inter-AS IP multicast. The topology and additional configuration templates are published on GitHub, with the experience also documented in a LinkedIn post. ### Source excerpt Aleksandr Albin built a large (almost 20-router) lab topology (based on an example from Jeff Doyle's Routing TCP/IP Volume 2) that he uses to practice inter-AS IP multicast. He also published the topology file (and additional configuration templates) on GitHub and documented his experience in a LinkedIn post. Lab topology, copied with permission by Aleksandr Albin It's so nice to see engineers using your tool in real-life scenarios. Thanks a million, Aleksandr, for sharing it. ## Comparing IP and CLNP: Local (Node) Multihoming DevFeed: [Comparing IP and CLNP: Local (Node) Multihoming]() Original publisher: [Read original article]() Published: 2025-04-02T07:21:00Z Content type: comparison Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Networks](), [Protocol (disambiguation)](), [Routing (disambiguation)](), [Firewall](), [Mainframe]() Tags: [firewall](), [ibm](), [ip](), [networking-fundamentals](), [networks](), [protocol](), [routing](), [stateful](), [tcp](), [tcp-ip]() ### AI overview The article compares local node multihoming in IP/TCP/IP and CLNP. It explains that TCP/IP multihomed hosts use multiple IP addresses and lack a single well-defined behavior, with strong and weak end-system models leading to routing asymmetry and complications for stateful firewalls. It describes loopback addressing and routing advertisements as a TCP/IP solution. The supplied excerpt is incomplete. ### Source excerpt Another area where CLNP is a clear winner when compared to the TCP/IP stack is multi-homed nodes (nodes with multiple interfaces, not site multi-homing, where whole networks are connected to two upstream providers). Multi-homed TCP/IP nodes must have multiple IP addresses because IP uses address interfaces. There is no well-defined procedure in TCP/IP for how a multi-homed node should behave. In the early days of TCP/IP, they tried to address that in RFC 1122 (Host Requirements RFC), but even then, there were two ideas about dealing with multiple interfaces: the strong and weak end system models (more details). Read more ... ## Comparing IP and CLNP: Network State Summarization DevFeed: [Comparing IP and CLNP: Network State Summarization]() Original publisher: [Read original article]() Published: 2025-03-19T06:59:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [IP routing](), [networking](), [IS-IS](), [Protocol (disambiguation)](), [BGP]() Tags: [bgp](), [ip-routing](), [ipv6](), [is-is](), [networking-fundamentals](), [routing](), [tcp-ip]() ### AI overview This article compares how TCP/IP and CLNP summarize network state in routing protocols. It explains that TCP/IP routing generally provides subnet, intra-area, and inter-area summarization levels, while most CLNP networks used two levels based on node and area addresses, with BGP enabling additional levels in either design. ### Source excerpt In the previous blog posts, we discussed how TCP/IP and CLNP reach adjacent nodes and build ARP/ND/ES caches and how they reach off-subnet nodes. Now, let's move from the network edge into the network core and explore how the two protocol stacks reduce the amount of information they have to propagate in routing protocols. While I'm not exactly an OSI fan, I must admit they got many things right (and IPv6 copied those ideas), but TCP/IP is a clear winner in this aspect. Read more ... ## Comparing IP and CLNP: Finding Adjacent Nodes DevFeed: [Comparing IP and CLNP: Finding Adjacent Nodes]() Original publisher: [Read original article]() Published: 2024-10-17T07:10:00Z Content type: comparison Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [TCP/IP](), [Protocol (disambiguation)](), [data]() Tags: [arp](), [interfaces](), [ip](), [ipv4](), [ipv6](), [network](), [networking](), [networking-fundamentals](), [protocol](), [tcp](), [tcp-ip]() ### AI overview The article compares TCP/IP and CLNP approaches to finding adjacent nodes. TCP/IP uses subnet masks to determine whether a destination is directly reachable and ARP or Neighbor Discovery to resolve the destination link-layer address, while CLNP nodes advertise NSAP addresses through hello messages that neighboring nodes cache. ### Source excerpt Now that we know a bit more about addresses in a networking stack (read the whole series) and why CLNP uses node addresses while TCP/IP uses interface addresses, let's see how they solve common addressing problems like finding adjacent nodes. Let's start with the elephant in the room: how do you know whether you can reach a host you want to communicate with directly? In the following diagram, how does A know whether B is sitting next to it? Read more ... ## The origins of the Idle Scan DevFeed: [The origins of the Idle Scan]() Original publisher: [Read original article]() Published: 2023-10-19T10:40:27Z Content type: article Language: en Sources: [Antirez]() Topics: [Network](), [TCP/IP](), [Operating system](), [Tool](), [Protocol (disambiguation)]() Tags: [attacks](), [network](), [operating-systems](), [protocol](), [research](), [tcp](), [tcp-ip](), [tool](), [udp]() ### AI overview The article recounts how the Idle scan originated in 1998 through experimentation with Hping, a tool for crafting unusual TCP/IP packets. It explains that observing incrementing IP ID values revealed a universal outgoing-packet counter in operating systems, which could be used to estimate a networked computer's outgoing traffic. ### Source excerpt The Idle scan was conceived at the end of 1998, evidenced by emails. I had moved to Milan a few months prior, having been there since September if I recall correctly, brimming with new ideas, unaware that my stay in that city would be brief. I spent the summer on the beaches of Sicily, mainly occupied with reading many books recommended by the folks at Seclab (mostly by David). However, those readings needed a catalyst: the Idle scan was an attack born from theoretical rumination, but the stream of thoughts originated from a rather practical circumstance. I had recently created Hping, a tool whose logo was borrowed from that of Nutella. I mention this to emphasize the seriousness that governed my efforts at that time -- after all, I was only twenty-one and already in Northern Italy with a full-time job on my shoulders; some understanding was warranted. Hping was a Swiss Army knife for the TCP/IP protocol. Its initial use was mostly exploratory, for research. With Hping, you could assemble TCP, UDP, and ICMP packets in the most bizarre manner, and encapsulate them in equally eccentric IP packets, fragmented, with fields set to anomalous values. These packets were sent around to observe the network stack response of different operating systems. This is where Idle scan originates: playing with Hping for just a few minutes revealed a well-known yet (to me) surprising fact. The response packets had an ID field that continuously incremented by some measure. At that time, given that the attacks I would later disclose were not yet known, this ID field behavior aroused no concern. Every time an operating system emitted an IP packet, it first incremented a counter (which reset to zero once it reached the maximum value of two to the sixteenth power minus one), then the packet was sent with the ID set to the counter's value. The counter was universal for all outgoing packets. This allowed, for starters, to estimate the outgoing traffic of any networked computer. This information ## How to use Postgres at the Edge DevFeed: [How to use Postgres at the Edge]() Original publisher: [Read original article]() Author: Paul Scanlon Published: 2023-09-19T15:33:04Z Content type: tutorial Language: en Sources: [Blog -- Neon Docs]() Topics: [Databases](), [Next.js](), [Serverless](), [Vercel](), [WebSocket](), [API](), [SQL]() Tags: [3d](), [api](), [community](), [data](), [demo](), [geolocation](), [how-to](), [http](), [next-js](), [npm](), [postgres](), [serverless](), [sql](), [statistics](), [tcp](), [tcp-ip](), [vercel]() ### AI overview This tutorial explains how to use Neon's serverless driver with Next.js and Vercel Edge Functions to access a serverless Postgres database. It shows how HTTP and WebSockets connect Edge-based applications to Postgres through a Neon proxy, and includes a demo that records geolocation data and visualizes the request journey. ### Source excerpt In this post, I'd like to introduce Neon's serverless driver which is suitable for use with Vercel Edge Functions. I'll explain how to use it with Next.js and a free Neon serverless Postgres database Here's a demo I created. I've called it Ping Thing. What does Ping Thing do? Whe... ## Service Performance at Capacity: Request Rate, Throughput, and Graceful Behavior DevFeed: [Service Performance at Capacity: Request Rate, Throughput, and Graceful Behavior]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2023-08-07T16:00:00Z Content type: article Language: en Sources: [Nelson Elhage]() Topics: [systems](), [servers](), [web applications](), [Back end](), [TCP/IP](), [Firewall](), [Networks](), [Python]() Tags: [architecture](), [backend](), [capacity](), [firewall](), [http](), [network](), [performance](), [python](), [tcp-ip]() ### AI overview The article examines service performance by relating incoming request rate to successful throughput. It introduces these metrics through examples involving an HTTP web application and a TCP/IP router or firewall. ### Source excerpt Suppose we've got a service. We'll gloss over the details for now, but let's stipulate that it accepts requests from the outside world, and takes some action in response. Maybe those requests are HTTP requests, or RPCs, or just incoming packets to be routed at the network layer. We can get more specific later. What can we say about its performance? All we know is that it receives requests, and that it acts on them. ## Reverse-engineering tcpip.sys: mechanics of a packet of the death (CVE-2021-24086) DevFeed: [Reverse-engineering tcpip.sys: mechanics of a packet of the death (CVE-2021-24086)]() Original publisher: [Read original article]() Author: Axel "0vercl0k" Souchet Published: 2021-04-15T15:00:00Z Content type: tutorial Language: en Sources: [Diary of a reverse-engineer]() Topics: [Reverse Engineering](), [Vulnerabilities](), [Cybersecurity](), [TCP/IP](), [Windows](), [Kernel]() Tags: [cve-2021-24086](), [fragmentation](), [ipv6preassembledatagram](), [kernel](), [poc](), [recursive-fragmentation](), [reverse-engineering](), [tcp-ip](), [tcpip-sys](), [vulnerabilities](), [windows]() ### AI overview This article reverse-engineers CVE-2021-24086, a remotely triggerable NULL dereference in the Windows TCP/IP kernel code. It explains the patch-diffing and reverse-engineering process, the network-buffer condition behind the flaw, and the development of a proof of concept. ### Source excerpt Introduction Since the beginning of my journey in computer security I have always been amazed and fascinated by true remote vulnerabilities. By true remotes, I mean bugs that are triggerable remotely without any user interaction. Not even a single click. As a result I am always on the lookout for ... ## An Introduction to DNS Traffic Management DevFeed: [An Introduction to DNS Traffic Management]() Original publisher: [Read original article]() Author: Raphaël Beamonte Published: 2020-08-05T14:48:00Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [distributed-systems](), [Internet](), [Networks](), [Unix]() Tags: [distributed-systems](), [dns](), [history](), [internet](), [network](), [networks](), [overview](), [tcp-ip]() ### AI overview An introduction to DNS traffic management, explaining its role in distributed-system resilience and outlining the history and purpose of the Domain Name System. ### Source excerpt Distributed systems are only as resilient as we build them to be. Domain Name System (DNS) traffic management is a well-used approach to do so. In this first part of a two-part series, we aim to give a broad overview of DNS and how it's used for traffic management, as well as the different reasons why we want to use DNS traffic management. ## Jane Street's 2018 Intern Projects in Networking, Linux Security, and OCaml Web UIs DevFeed: [Jane Street's 2018 Intern Projects in Networking, Linux Security, and OCaml Web UIs]() Original publisher: [Read original article]() Author: Yaron Minsky Published: 2018-08-06T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [networking](), [TCP/IP](), [Linux](), [Security](), [firewalls](), [OCaml](), [JavaScript](), [Framework](), [Go]() Tags: [firewalls](), [framework](), [hardware](), [incremental](), [internship](), [javascript](), [linux](), [networking](), [ocaml](), [performance](), [tcp](), [tcp-ip](), [ui]() ### AI overview Jane Street reviews a selection of its 2018 intern projects, including a user-level TCP/IP stack, Linux kernel and firewall configuration through netlink sockets, and improvements to Incr_dom, an OCaml framework for efficient JavaScript web UIs. The article also discusses the performance demands of financial-market networking and user-space network stacks. ### Source excerpt Yet again, intern season is coming to a close, and so it's time to look back at what the interns have achieved in their short time with us. I'm always impressed by what our interns manage to squeeze into the summer, and this year is no different. ## Tweaking TCP for Real-time Applications: Nagle's Algorithm and Delayed Acknowledgment DevFeed: [Tweaking TCP for Real-time Applications: Nagle's Algorithm and Delayed Acknowledgment]() Original publisher: [Read original article]() Author: umer Published: 2017-03-19T00:00:00Z Content type: tutorial Language: en Sources: [Code Ahoy - Articles]() Topics: [TCP/IP](), [real-time](), [Protocol (disambiguation)](), [Algorithm]() Tags: [algorithm](), [data-transmission](), [protocol](), [real-time](), [tcp-ip]() ### AI overview This tutorial explains how TCP buffering techniques affect real-time applications that send small messages. It focuses on Nagle's algorithm, which combines small messages to reduce packet overhead, and introduces TCP delayed acknowledgment. The article notes that Nagle's algorithm can create performance issues for multiplayer gaming servers. ### Source excerpt TCP is a complex protocol. Don't get me wrong. It is a marvelous piece of engineering that gives us the reliable data transmission guarantee that other protocols don't provide. Reliable data transmission between two devices on the internet is no walk in the park and TCP uses a lot of magic under the hood to make things happen. Generally, it does a fine job of abstracting away low level details and its default settings work fine for most general purpose use cases. However, once in a while, things don't go according to plan and we need to pop open the hood and do some tweaking. It is in these situations, that some knowledge of TCP comes in very handy. By default, TCP uses two buffering techniques to optimize and minimize overhead for general purpose applications. However, if you are building applications that require real-time message delivery for small messages (e.g. chat or control messages), you must have some knowledge of these techniques. Nagle's algorithm TCP delayed acknowledgment Let's look at them in more detail. Nagle's Algorithm If there's no congestion, TCP tacks on a header and sends data out as soon as it gets it from the application. If the application is generating a lot of small messages, the headers can add a lot of overhead: TCP/IP headers are 40-byte, so 1-byte of data is sent as 41-byte packet on the network. A computer programmer named John Nagle came up with an algorithm to reduce the overhead by combining many small messages into a single message. Nagle's algorithm, named after its inventor, is a technique to make TCP more efficient by reducing the number of packets that are sent over the network. Here's the pseudo code for the algorithm: if there is new data to send if the window size >= MaximumSegmentSize and available data is >= MaximumSegmentSize send complete MaximumSegmentSize segment now else if there is unconfirmed data still in the pipe enqueue data in the buffer until an acknowledge is received else send data immediately end if end if ## Why the select I/O multiplexing model is considered broken by design DevFeed: [Why the select I/O multiplexing model is considered broken by design]() Original publisher: [Read original article]() Author: Marek Published: 2017-01-05T23:00:00Z Content type: opinion Language: en Sources: [Marek Majkowski]() Topics: [IO](), [TCP/IP](), [Linux](), [Kernel](), [file]() Tags: [article](), [async](), [blog](), [kernel](), [tcp-ip]() ### AI overview This article examines alternatives for I/O multiplexing and argues that the select model is broken by design because its semantics prevent effective kernel-side optimizations. It also discusses related technologies that inherit those semantics. ### Source excerpt Select is fundamentally broken I/O multiplexing part #2 In a previous blog post we discussed a brief history of the syscall. The article concludes that some I/O multiplexing was necessary to do console emulation, games and non-trivial TCP/IP applications. The BSD designers chose the multiplexing model and other Unixes followed. But is the only multiplexing model? A good explanation can be found in the old revision of "The Design and Implementation of the FreeBSD Operating System" book. ## Google SoC lwIP Conclusion DevFeed: [Google SoC lwIP Conclusion]() Original publisher: [Read original article]() Published: 2016-08-23T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [lwIP](), [TCP/IP](), [Operating system]() Tags: [c](), [conclusion](), [free](), [google](), [kernel](), [lwip](), [open-source](), [os](), [react](), [reactos](), [tcp-ip](), [threading](), [udp](), [win32](), [winapi]() ### AI overview A Google Summer of Code participant reports on developing TCP and UDP support for ReactOS using lwIP. The project did not achieve full browser support or a Windows Server 2003 driver replacement, but produced a fairly robust TCP/IP driver for C console applications using TCP and UDP sockets, with extensive testing on loopback. ### Source excerpt My Google Summer of Code project proposal stated that I would add TCP support to the network branch of ReactOS, which sought to integrate lwIP 1.4.1 as the protocol level network driver for the operating system, to ultimately be tested by replacing the network driver in an installation of Windows Server 2003 with my driver. The full proposal can be found here. At the time of my proposal, I underestimated the amount of effort a fully working network driver would take. ## Returning to the Original Social Network DevFeed: [Returning to the Original Social Network]() Original publisher: [Read original article]() Published: 2016-07-08T00:00:00Z Content type: article Language: en Sources: [Joe Nelson]() Topics: [Internet](), [Networks](), [Network]() Tags: [distributed](), [dns](), [free](), [guide](), [history](), [internet](), [network](), [networks](), [registry](), [search](), [tcp-ip]() ### AI overview This article argues for a return to a more distributed model of online communication centered on personal domain names, DNS, and email rather than centralized social networks. It explains domain leasing, registry operators, accredited registrars, and the process of finding and registering an available domain. ### Source excerpt 2016-07-08 Something has been lost. Before algorithmic timelines, message length restrictions and mass surveillance there was a more robust world. It's a distributed world that still lives behind the centralized allure of social networks. It's a world where every person owns a small part of the internet, where they control their medium and communicate freely. I'm referring to the domain name system and email. You may think that you take full advantage of them, but I suspect you don't. ## Google SoC lwIP Report Week 1 DevFeed: [Google SoC lwIP Report Week 1]() Original publisher: [Read original article]() Published: 2016-05-27T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [lwIP](), [TCP/IP](), [systems](), [Programming](), [Google]() Tags: [bug](), [debug](), [free](), [google-summer-of-code](), [lwip](), [open-source](), [os](), [programming](), [react](), [reactos](), [systems](), [tcp-ip](), [win32](), [winapi]() ### AI overview A first-week report on integrating lwIP into ReactOS during Google Summer of Code. The author describes testing a Winsock TCP server-client pair, debugging ReactOS kernel-mode drivers, fixing a socket binding bug, and investigating TCP connection establishment while noting that many TCP functions remain unimplemented. ### Source excerpt Note: I am publishing these but each student is responsible for actually writing them. I am Zuodian Hu or, as I like to be called, Dian (pronounced the same as Dan). I just finished my junior year at the University of Wisconsin at Madison, where I am working on an electrical engineering and computer science double major. My personal interest lies in systems programming and digital logic. In addition to my classes, I play violin in the UW-Madison symphony orchestra and do programming for Wisconsin Robotics and the UW-Madison team competing in the NASA Robotics Mining Competition. ## Bind before connect DevFeed: [Bind before connect]() Original publisher: [Read original article]() Author: Marek Published: 2014-04-02T22:00:00Z Content type: tutorial Language: en Sources: [Marek Majkowski]() Topics: [Linux Kernel](), [TCP/IP](), [API](), [Code](), [Python]() Tags: [article](), [linux](), [linux-kernel](), [nat](), [port](), [python](), [socket](), [tcp-ip]() ### AI overview This article explains how the Linux kernel allocates source ports for TCP/IP connections, including ephemeral port selection, port reuse, connection limits, and the bind-before-connect technique. ### Source excerpt Bind before connect A TCP/IP connection is identified by a four element tuple: {source IP, source port, destination IP, destination port}. To establish a TCP/IP connection only a destination IP and port number are needed, the operating system automatically selects source IP and port. This article explains how the Linux kernel does the source port allocation. Ephemeral port range To establish a connection BSD API requires two steps: first you need to create a socket, then call on it. ## Fun with The Great Firewall DevFeed: [Fun with The Great Firewall]() Original publisher: [Read original article]() Author: Marek Published: 2013-07-10T22:00:00Z Content type: opinion Language: en Sources: [Marek Majkowski]() Topics: [Firewall](), [tor](), [TCP/IP]() Tags: [firewall](), [iptables](), [payload](), [port](), [servers](), [ssl](), [tcp-ip](), [tor]() ### AI overview The article describes observations of how China's Great Firewall probes and blocks Tor bridges. It reports that detected Tor bridges may have their IP-and-port tuples blocked for hours, while later probing behavior appeared to vary over time and was not fully understood. ### Source excerpt Fun with The Great Firewall I was playing with the Tor Project and decided to understand how the Chinese block Tor servers. Philipp Winter wrote an amazing paper on that subject. He noticed The Great Firewall of China is actively scanning services and if it detects a Tor bridge it blocks the ip:port tuple for a few hours. TCP/IP When a port gets censored "ACK" packets are dropped by the GFW. Most importantly and . ## FOSDEM 2013 DevFeed: [FOSDEM 2013]() Original publisher: [Read original article]() Published: 2013-02-05T00:00:00Z Content type: article Language: en Sources: [Radek Pazdera]() Topics: [FOSDEM](), [Open Source](), [GNU/Hurd](), [Kernel](), [TCP/IP]() Tags: [conference](), [developers](), [fosdem](), [gnu-hurd](), [kernel](), [open-source](), [report](), [tcp-ip]() ### AI overview A personal report on attending FOSDEM 2013 in Brussels, including a presentation of the LNST project and observations from talks about GNU/Hurd and its modular design. ### Source excerpt My report from the Free and Open Source Developers' European Meeting ## Stripping layer 2 in pcap DevFeed: [Stripping layer 2 in pcap]() Original publisher: [Read original article]() Author: Marek Published: 2013-01-28T23:00:00Z Content type: tutorial Language: en Sources: [Marek Majkowski]() Topics: [Network](), [TCP/IP](), [Code](), [Decoding]() Tags: [code](), [decoding](), [network](), [tcp-ip]() ### AI overview The article explains why extracting IP headers from captured TCP/IP packets requires removing the layer 2 header first. It discusses data-link types, hardcoded offsets, VLAN headers, and differing strategies for decoding packet layouts. ### Source excerpt Stripping layer 2 in pcap Say you want to sniff TCP/IP packets on your network. That's pretty easy, right? Use , receive packets from the network interface and we're done. But before you can extract the IP header from a received packet you need to strip layer 2 header. It's not that easy. tries to help only a bit - it is possible to get the data link type of the network interface. But this is useless without the knowledge of how to extract IP from given data link type. ## SSL fingerprinting for p0f DevFeed: [SSL fingerprinting for p0f]() Original publisher: [Read original article]() Author: Marek Published: 2012-06-16T22:00:00Z Content type: article Language: en Sources: [Marek Majkowski]() Topics: [SSL](), [HTTP](), [TCP/IP](), [browser](), [Chrome](), [Firefox]() Tags: [chrome](), [compression](), [firefox](), [handshake](), [handshakes](), [http](), [ssl](), [tcp-ip](), [tls]() ### AI overview The article describes SSL/TLS fingerprinting for p0f. It explains how client cipher suites, extensions, ordering, protocol versions, and other handshake details can identify SSL clients such as browsers, and discusses a p0f module that matches generated fingerprints against predefined signatures. ### Source excerpt SSL fingerprinting for p0f In January Lcamtuf announced a complete rewrite of his passive fingerprinting tool p0f. Historically p0f was a low-level tool focused on fingerprinting layer 4, mostly and TCP/IP packets. The new version of p0f is different: not only it can look at low level packets, but also it is capable of fingerprinting higher-level application protocols. Currently it is able to do HTTP fingerprinting and the author suggests other protocols might soon follow. ## ReactOS 0.3.14 Released DevFeed: [ReactOS 0.3.14 Released]() Original publisher: [Read original article]() Published: 2012-02-08T00:00:00Z Content type: release Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [networking](), [TCP/IP](), [lwIP]() Tags: [free](), [lwip](), [open-source](), [os](), [react](), [reactos](), [release](), [tcp-ip](), [win32](), [winapi]() ### AI overview ReactOS 0.3.14 was released with networking, user-interface, kernel-testing, and build-toolchain improvements. The release adds a TCP/IP driver built around lwIP, wireless networking support, theme support, and MSVC-based builds. ### Source excerpt The ReactOS team is proud to announce the release of ReactOS 0.3.14. This version includes a significant amount of changes including both user visible and architectural improvements. Also included in this release is the valuable work accomplished as part of the Google Summer of Code 2011 event, of which ReactOS was a mentoring project. One of the more significant sets of improvements was to ReactOS' networking stack. As part of the GSoC, ReactOS gained a new TCP/IP driver built around the LwIP project. [Next page]()