Salted. s

Using Apple Metal to accelerate DPI recognition

Thu, 18 Jun 2026 00:00:00 +0900

GPU acceleration for DPI sounds attractive, but the wrong design can make a router slower. The expensive part is not just “running math.” The expensive part is moving packet data, synchronizing CPU and GPU work, and deciding which packets deserve the GPU path.

Apple Metal is interesting for DPI because Apple Silicon has a unified memory architecture. The CPU and GPU can both access system memory. That does not mean data movement is free. It means the design can avoid explicit PCIe-style copies and instead spend most of its effort on batching, cache-friendly layout, and synchronization.

Thoughts on BBR congestion control in QUIC under high loss

Thu, 18 Jun 2026 00:00:00 +0900

BBR is a natural fit for QUIC, but it is not magic. It works well when packet loss is a bad congestion signal. It can work poorly when loss corrupts the measurements that BBR itself needs.

That distinction matters on high-loss networks: long-distance wireless, satellite, overloaded mobile backhaul, Wi-Fi with interference, tunnels over lossy UDP, and any path where packets disappear even when the bottleneck queue is not full.

The simple position is:

Recognizing encrypted P2P and BitTorrent traffic from packet patterns

Thu, 18 Jun 2026 00:00:00 +0900

Encrypted P2P detection is not magic string matching. Once the peer wire payload is encrypted, a DPI engine cannot honestly say “I read BitTorrent from the payload.” What it can say is weaker and more useful:

this flow behaves like encrypted P2P with probability high enough to classify.

That is the right mental model. For plain BitTorrent, the early TCP stream is easy: the peer wire handshake starts with a one-byte length followed by the string BitTorrent protocol. For encrypted BitTorrent, that obvious header is gone. BEP 8 explicitly points out that Message Stream Encryption makes peer connections harder to identify because bytes are encrypted from the beginning of the peer connection.

GRE over WireGuard mesh with BGP and BIRD

Thu, 18 Jun 2026 00:00:00 +0900

A WireGuard mesh gives each site a secure underlay. BGP gives each site a way to tell the rest of the network which prefixes it can reach. GRE, placed inside WireGuard, gives each adjacency a normal point-to-point tunnel interface that Linux, BIRD, firewall rules, and monitoring tools can treat like any other routed link.

The result is a multihomed private intranet: a house, VPS, office, and travel router can all announce their local LAN prefixes, learn the other LAN prefixes, and reroute when a link becomes slow or fails.

Using DPI to distinguish QUIC, HTTP/3, and HTTP/2

Wed, 17 Jun 2026 00:00:00 +0900

Deep packet inspection for modern web traffic is less about reading application payloads and more about making fast decisions from the few bytes that are still visible. That is especially true for QUIC. After the handshake, QUIC encrypts almost everything a middlebox would like to inspect. If the DPI engine misses the first few packets, later packets often only say: “this is probably a QUIC connection that I should have classified earlier.”

Country-based routing made fast

Wed, 18 Oct 2023 00:00:00 +0900

Country-based routing sounds simple: if the destination IP belongs to a country, send it through a different WAN or VPN; otherwise use the normal default route. On OpenWrt, the slow version is also simple: download a country CIDR list and append thousands of firewall rules.

That works until it does not. A country list can contain thousands or tens of thousands of prefixes. If each packet has to walk a long linear rule chain before the router can choose an output interface, the router is doing routing policy work in one of the hottest parts of the network stack.

Split routing using netfilter

Sat, 11 Jan 2020 00:00:00 +0900

Split routing, also called policy-based routing, means sending only some traffic through a different route while leaving the rest of the network alone. A common example is an OpenWrt router where normal traffic exits through the ISP WAN, but traffic for a few destination networks, a specific LAN host, or a specific service goes through a VPN tunnel.

On older OpenWrt releases this was usually done with iptables mangle rules. On current OpenWrt releases, the firewall is firewall4 (fw4), which uses nftables as its backend. The idea is the same, but the rule language and the way OpenWrt loads custom rules are different.

AND (Average Network Delay) and Queuing Theory Basics

Sun, 06 May 2018 00:00:00 +0900

Recently I was looking at the Linear programming formulations of Traffic engineering problems and one of the problems is to find the path with the goal to minimize the Average network delay. Which got me thinking that for topology design related problems, how can I calculate the Average network delay? As you can guess, I’m going to introduce the model we implemented in Hokkaido research network.

Before starting few things to keep in mind:

A background in Probability theory, particularly familiarity with Poisson and Exponential distribution will help. There is no way I can do the justice in explaining all the basics without distracting from the main goal.
I will involve Queuing theory and the Math involved in Queuing theory gets complicated very fast, especially for an average guy like me. What we are going to look at is the most basic form.
Please be aware that whatever we cover here only allows us to measure the first order approximation of what happens in real life and it is good for use cases like topology design but not for measuring the exact state of a network for operational purposes.
As usual disclaimer, I am going to take some luxuries while explaining to keep things simple, so it’s possible that some statements may not be mathematically accurate.

Difference between OpenVZ and LXC

Sun, 31 Dec 2017 00:00:00 +0900

Background: What’s a container?

Containers have been around for over 15 years, so why is there an influx of attention for containers? As compute hardware architectures become more elastic, potent, and dense, it becomes possible to run many applications at scale while lowering TCO, eliminating the redundant Kernel and Guest OS code typically used in a hypervisor-based deployment. This is attractive enough but also has benefits such as eliminating performance penalties, increase visibility and decrease difficulty of debug and management.

BitTorrent Traffic Detection with Deep Flow Inspection

Sat, 23 Dec 2017 00:00:00 +0900

1. What is Deep Flow Inspection(DFI)?

As the name implies, the analysis or the classification of P2P traffic is a flow-based, focusing on the connection level patterns of P2P applications. Thus, it does not require any payload analysis, unlike DPI. Because it doesn’t require payload analysis, encrypted data packets can be easily supported. The down side of this approach is that there is an additional step of extracting the connection level pattern for the P2P traffics. And yet, there is no rule of thumb for which network feature should be used in this method.

Advanced Materials Through AI & Computational Materials Science

Fri, 19 May 2017 00:00:00 +0900

A recent Nature article examines how materials researchers are using artificial intelligence to accelerate quantum-mechanical calculations. Work that once required hours on supercomputers can now, in some cases, be completed in only a few seconds.

These computer-modeling and machine-learning techniques are making it possible to generate enormous libraries of potential materials. Researchers hope this approach will greatly increase both the speed and the practical value of materials discovery. British materials scientist Neil Alford captures the importance of this shift: “We are now seeing a real convergence of what experimentalists want and what theorists can deliver.”

Differences between TLS 1.2 and TLS 1.3

Fri, 19 Feb 2016 00:00:00 +0900

The current version of TLS, TLS 1.2, was defined in RFC 5246 and has been in use for the past eight years by the majority of all web browsers. Companies such as Cloudflare are already making TLS 1.3 available to their customers.

With the release of TLS 1.3, there are promises of enhanced security and speed. But how exactly do the changes from TLS 1.2 to TLS 1.3 cause these improvements? The following is a list of differences between TLS 1.2 and 1.3 that shows how the improvements are achieved.

Sending raw Ethernet packets from a specific interface in C on Linux

Sat, 19 Dec 2015 00:00:00 +0900

Lately I’ve been writing some code to send packets to a specific MAC address from a specific interface. I’m sure this will come in handy again so here is how it goes:

Includes

 #include <netinet/in.h>
 #include <sys/socket.h>
 #include <arpa/inet.h>
 #include <net/if.h>
 #include <netinet/ip.h>
 #include <netinet/udp.h>
 #include <netinet/ether.h>
 #include <linux/if_packet.h>

Open the raw socket:

 int sockfd;
 ...
 /* Open RAW socket to send on */
 if ((sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW)) == -1) {
 perror("socket");
 }

Get the index of the interface to send on:

 struct ifreq if_idx;
 ...
 memset(&if_idx, 0, sizeof(struct ifreq));
 strncpy(if_idx.ifr_name, "eth0", IFNAMSIZ-1);
 if (ioctl(sock, SIOCGIFINDEX, &if_idx) < 0)
 perror("SIOCGIFINDEX");

Get the MAC address of the interface to send on:

 struct ifreq if_mac;
 ...
 memset(&if_mac, 0, sizeof(struct ifreq));
 strncpy(if_mac.ifr_name, "eth0", IFNAMSIZ-1);
 if (ioctl(sock, SIOCGIFHWADDR, &if_mac) < 0)
 perror("SIOCGIFHWADDR");

Get the IP address of the interface to send on:

 struct ifreq if_ip;
 ...
 memset(&if_ip, 0, sizeof(struct ifreq));
 strncpy(if_ip.ifr_name, "eth0", IFNAMSIZ-1);
 if (ioctl(sock, SIOCGIFADDR, &if_ip) < 0)
 perror("SIOCGIFADDR");

Construct the Ethernet header:

 int tx_len = 0;
 char sendbuf[1024];
 struct ether_header *eh = (struct ether_header *) sendbuf;
 ...
 memset(sendbuf, 0, 1024);
 /* Ethernet header */
 eh->ether_shost[0] = ((uint8_t *)&if_mac.ifr_hwaddr.sa_data)[0];
 eh->ether_shost[1] = ((uint8_t *)&if_mac.ifr_hwaddr.sa_data)[1];
 eh->ether_shost[2] = ((uint8_t *)&if_mac.ifr_hwaddr.sa_data)[2];
 eh->ether_shost[3] = ((uint8_t *)&if_mac.ifr_hwaddr.sa_data)[3];
 eh->ether_shost[4] = ((uint8_t *)&if_mac.ifr_hwaddr.sa_data)[4];
 eh->ether_shost[5] = ((uint8_t *)&if_mac.ifr_hwaddr.sa_data)[5];
 eh->ether_dhost[0] = MY_DEST_MAC0;
 eh->ether_dhost[1] = MY_DEST_MAC1;
 eh->ether_dhost[2] = MY_DEST_MAC2;
 eh->ether_dhost[3] = MY_DEST_MAC3;
 eh->ether_dhost[4] = MY_DEST_MAC4;
 eh->ether_dhost[5] = MY_DEST_MAC5;
 eh->ether_type = htons(ETH_P_IP);
 tx_len += sizeof(struct ether_header);

Construct the IP header:

 struct iphdr *iph = (struct iphdr *) (sendbuf + sizeof(struct ether_header));
 ...
 /* IP Header */
 iph->ihl = 5;
 iph->version = 4;
 iph->tos = 16; // Low delay
 iph->id = htons(54321);
 iph->ttl = ttl; // hops
 iph->protocol = 17; // UDP
 /* Source IP address, can be spoofed */
 iph->saddr = inet_addr(inet_ntoa(((struct sockaddr_in *)&if_ip.ifr_addr)->sin_addr));
 // iph->saddr = inet_addr("192.168.0.112");
 /* Destination IP address */
 iph->daddr = inet_addr("192.168.0.111");
 tx_len += sizeof(struct iphdr);

Construct the UDP header:

 struct udphdr *udph = (struct udphdr *) (sendbuf + sizeof(struct iphdr) + sizeof(struct ether_header));
 ...
 /* UDP Header */
 udph->source = htons(3423);
 udph->dest = htons(5342);
 udph->check = 0; // skip
 tx_len += sizeof(struct udphdr);

Fill in UDP payload:

 /* Packet data */
 sendbuf[tx_len++] = 0xde;
 sendbuf[tx_len++] = 0xad;
 sendbuf[tx_len++] = 0xbe;
 sendbuf[tx_len++] = 0xef;

Fill in remaining header info:

 unsigned short csum(unsigned short *buf, int nwords)
 {
 unsigned long sum;
 for(sum=0; nwords>0; nwords--)
 sum += *buf++;
 sum = (sum >> 16) + (sum &0xffff);
 sum += (sum >> 16);
 return (unsigned short)(~sum);
 }
 ...
 /* Length of UDP payload and header */
 udph->len = htons(tx_len - sizeof(struct ether_header) - sizeof(struct iphdr));
 /* Length of IP payload and header */
 iph->tot_len = htons(tx_len - sizeof(struct ether_header));
 /* Calculate IP checksum on completed header */
 iph->check = csum((unsigned short *)(sendbuf+sizeof(struct ether_header)), sizeof(struct iphdr)/2);

Send the raw Ethernet packet:

 /* Destination address */
 struct sockaddr_ll socket_address;
 ...
 /* Index of the network device */
 socket_address.sll_ifindex = if_idx.ifr_ifindex;
 /* Address length*/
 socket_address.sll_halen = ETH_ALEN;
 /* Destination MAC */
 socket_address.sll_addr[0] = MY_DEST_MAC0;
 socket_address.sll_addr[1] = MY_DEST_MAC1;
 socket_address.sll_addr[2] = MY_DEST_MAC2;
 socket_address.sll_addr[3] = MY_DEST_MAC3;
 socket_address.sll_addr[4] = MY_DEST_MAC4;
 socket_address.sll_addr[5] = MY_DEST_MAC5;
 /* Send packet */
 if (sendto(sock, sendbuf, tx_len, 0, (struct sockaddr*)&socket_address, sizeof(struct sockaddr_ll)) < 0)
 printf("Send failed\n");

Code available here

Drive Headless Chromium with Python3

Fri, 19 Jun 2015 00:00:00 +0900

Browser Automation

Before we dive into any code, let’s talk about what a headless browser is and why it’s useful. In short, headless browsers are web browsers without a graphical user interface (GUI) and are usually controlled programmatically or via a command-line interface.

One of the many use cases for headless browsers is automating usability testing or testing browser interactions. If you’re trying to check how a page may render in a different browser or confirm that page elements are present after a user initiates a certain workflow, using a headless browser can provide a lot of assistance. In addition to this, traditional web-oriented tasks like web scraping can be difficult to do if the content is rendered dynamically (say, via Javascript). Using a headless browser allows easy access to this content because the content is rendered exactly as it would be in a full browser.