DEV Community: Musa Nayyer

Store-and-Forward Explained: Inside a Router, From the Book to Linux

Musa Nayyer — Wed, 21 Oct 2026 19:56:44 +0000

Most of us studied circuit and packet switching as course material. Here is what it actually looks like inside a router.

The textbook defines store-and-forward in one sentence: a packet switch "must receive the entire packet before it can begin to transmit the first bit of the packet onto the outbound link" (Kurose & Ross, Computer Networking: A Top-Down Approach, 7th ed., section 1.3.1). That sentence leaves three questions open:

Why does the router wait?
What does it do with the packet while it holds it?
What does the waiting cost?

Scope: the router here is a Linux machine with IP forwarding on, because its source code is open. Hardware routers follow the same rules (RFC 1812 for IPv4) in specialized chips. Linux fast paths are left out. Kernel code is from mainline 7.3; function names can change between versions. Test system: Linux 7.2.7 (CachyOS), iproute2 7.2.0.

The parts build on one another:

Store: nothing leaves until the last bit arrives
Why wait: the error check is at the end
Forward: what Linux does with the frame
The four small edits at every hop
The cost: N × L/R
Why your data is cut into small packets
Not every box waits: cut-through switches

Part 1: Store: Nothing Leaves Until the Last Bit Arrives

The question

When the first bits of a packet reach a router, when does the router start sending them on?

What I found

Only after the last bit arrives. The router keeps incoming bits in a buffer until the whole packet is in, then sends it on the next link.

The time to push one packet onto a link is its transmission delay:

transmission delay = L / R

L = packet size in bits
R = link rate in bits per second

Example (round numbers, not a measurement): a 1500-byte packet on a 100 Mbps link.

1500 bytes × 8 = 12,000 bits
12,000 bits / 100,000,000 bits per second = 0.00012 s = 120 µs

The book's example: one router between two hosts, propagation delay ignored. The source needs L/R to send the packet, and the router needs another L/R because it starts only after the last bit. Total: 2L/R, not L/R.

Precision note: L here is the 1500-byte IP packet. Real Ethernet adds 18 bytes of frame (14-byte header, 4-byte FCS), plus an 8-byte preamble and a minimum 12-byte gap between frames. With those, 120 µs becomes about 123 µs. The examples keep 1500 bytes for round numbers.

Where the "store" happens on Linux

Storing starts in the network card. A typical NIC receives the frame, checks it (Part 2), and copies it to a ring buffer in RAM through DMA. The driver then hands the kernel the complete frame in an sk_buff (socket buffer). By the time routing code runs, the whole frame is already in memory.

Key idea

A router never forwards half a packet. Every link costs at least one full L/R, because the next device cannot start until the last bit has arrived.

Part 2: Why Wait? The Error Check Is at the End

The question

Waiting costs time. Why not send bits on as soon as they arrive?

What I found

One reason is the frame layout. An Ethernet frame ends with a 4-byte FCS (Frame Check Sequence), a CRC-32 value. The sender calculates it over the frame, from the destination MAC to the end of the data (including any padding), and sends it last.

The receiving card runs the same calculation on the bytes it got and compares:

Same value: no error detected. The frame moves on.
Different value: some bits were damaged. The card discards the frame.

Ethernet sends nothing back in either case: no acknowledgement on a pass, no negative acknowledgement on a fail (book, section 6.4.2). A bad frame just disappears, and higher layers such as TCP must notice the gap.

Because the FCS comes last, it can only be checked after the last byte arrives. Waiting stops a damaged frame at the first hop instead of carrying it across the network.

A second check happens at the IP layer: RFC 1812 (section 5.2.2) says a router must verify the IPv4 header checksum before processing a packet and must silently discard it if the checksum is wrong. The book counts bit-error checks as part of a router's processing delay (section 1.4.1).

Checking it on Linux

FCS errors are counted per interface. Two -s flags show the detailed error columns (enp7s0 is the wired interface):

ip -s -s link show dev enp7s0

Output, trimmed to the receive lines:

    RX:  bytes packets errors dropped  missed   mcast
    3943946473 2833648      0       0       0     465
    RX errors:  length    crc   frame    fifo overrun
                     0      0       0       0       0

The crc column counts frames with a bad FCS, as reported by the driver. It shows zero, but what it counts depends on the driver. The r8169 driver (drivers/net/ethernet/realtek/r8169_main.c), for example, counts only errored frames the card hands over, and with the default settings below, the card may drop them first. Some drivers also show hardware CRC counters in ethtool -S <interface>; r8169 has none named "crc".

Two card settings show what reaches the kernel:

ethtool -k enp7s0 | grep -E 'rx-fcs|rx-all'

rx-fcs: off
rx-all: off

From the kernel documentation (netdev-features): rx-fcs asks the card to "append the Ethernet Frame Checksum (FCS) to the end of the skb data", and rx-all asks it to "receive all possible frames, including errored frames (such as bad FCS, etc)". Both are off, the normal setting: frames with a bad FCS never reach the network stack, and good frames reach it without their FCS. With r8169, the driver trims the 4 FCS bytes (pkt_size -= ETH_FCS_LEN in r8169_main.c). That is why tcpdump normally shows no FCS, on either the receiving or the sending side.

The kernel counts IPv4 header checksum errors itself. In ip_rcv_core() (net/ipv4/ip_input.c), a failed ip_fast_csum() raises two counters before the packet is dropped:

nstat -az IpExtInCsumErrors IpInHdrErrors

#kernel
IpInHdrErrors                   0                  0.0
IpExtInCsumErrors               0                  0.0

Key idea

The error check sits at the end of the frame. A store-and-forward device must wait for it, and in return a damaged frame stops at the first hop.

Part 3: Forward: What Linux Does With the Frame

The question

Once the frame is stored and checked, what happens to it inside the router?

What I found

Linux only forwards packets when IP forwarding is on:

sysctl net.ipv4.ip_forward

net.ipv4.ip_forward = 1

1: the machine forwards packets not addressed to it. 0: it does not.

On a desktop, 1 is common when Docker is installed. Docker's documentation says it "enables the sysctl settings net.ipv4.ip_forward and net.ipv6.conf.all.forwarding" if they are not already enabled when it starts (except with its experimental nftables backend). So a Linux machine running Docker with its default setup already forwards packets, like a small router.

With forwarding on, one IPv4 packet takes this path (simplified; firewall hooks and fast paths left out unless noted):

Step	Where	What happens
1	NIC	Receives the whole frame, checks the FCS, copies it to RAM (Part 1 and 2)
2	`eth_type_trans()`	Reads the Ethernet header, then moves the packet's start pointer past its 14 bytes (`skb_pull`). The old header is not erased, just no longer part of the packet data
3	`ip_rcv_core()`	Basic IPv4 checks, including the header checksum
4	Route lookup	The destination is not this machine, so the route's input function is set to `ip_forward()` (`net/ipv4/route.c`)
5	`ip_forward()`	TTL and MTU checks, makes room in front of the packet for the new link-layer header, lowers the TTL
6	FORWARD hook	Firewall rules in the forward chain (iptables or nftables) run here
7	`ip_finish_output2()`	Finds the next hop's neighbor entry and writes the new Ethernet header
8	Driver and NIC	Hands the frame to the card, which normally adds the new FCS as it transmits

The core of ip_forward() (net/ipv4/ip_forward.c), shortened (... marks removed lines):

    /*
     *  According to the RFC, we must first decrease the TTL field. If
     *  that reaches zero, we must reply an ICMP control message telling
     *  that the packet's lifetime expired.
     */
    if (ip_hdr(skb)->ttl <= 1)
        goto too_many_hops;
    ...
    __IP_INC_STATS(net, IPSTATS_MIB_OUTFORWDATAGRAMS);
    ...
    /* We are about to mangle packet. Copy it! */
    if (skb_cow(skb, LL_RESERVED_SPACE(rt->dst.dev)+rt->dst.header_len))
        goto drop;
    iph = ip_hdr(skb);

    /* Decrease ttl after skb cow done */
    ip_decrease_ttl(iph);
    ...
too_many_hops:
    /* Tell the sender its packet died... */
    __IP_INC_STATS(net, IPSTATS_MIB_INHDRERRORS);
    icmp_send(skb, ICMP_TIME_EXCEEDED, ICMP_EXC_TTL, 0);

Three details matter here:

TTL is checked before it is lowered. A packet arriving with TTL 1 would leave with TTL 0, so it is dropped here and the sender gets ICMP Time Exceeded, as RFC 1812 (section 5.3.1) requires.
skb_cow() prepares the packet for editing. It ensures the router has its own writable copy and enough headroom for the outgoing link-layer header (LL_RESERVED_SPACE), the same headroom the kernel uses when building a packet on the sending side.
The new Ethernet header is usually copied, not built. Linux caches a ready-made link-layer header for each neighbor (next hop). neigh_hh_output() (include/net/neighbour.h) copies it into the headroom, right in front of the IP header. If the neighbor's MAC address is unknown, ARP resolves it first.

The MTU check: if the packet is larger than the next link's MTU and has the IPv4 "Don't Fragment" (DF) bit set, ip_forward() drops it and sends back ICMP "Fragmentation Needed". Without DF, the router may fragment it on the way out.

Checking it on Linux

These kernel counters match the code above:

nstat -az IpForwDatagrams IpInHdrErrors IcmpOutTimeExcds

Output:

#kernel
IpInHdrErrors                   0                  0.0
IpForwDatagrams                 30                 0.0
IcmpOutTimeExcds                0                  0.0

The counters start at zero at boot: 30 packets forwarded since then, none dropped for an expired TTL.

IpForwDatagrams rises in ip_forward() after a packet passes the TTL and policy checks.
An expired TTL counts under IpInHdrErrors (this path has no separate "TTL expired" counter); the ICMP reply counts under IcmpOutTimeExcds.

Key idea

Forwarding is a short, fixed list of steps: check, look up the route, lower the TTL, attach a new link-layer header, send. Each step is a few lines of kernel code you can read.

Part 4: The Four Small Edits at Every Hop

The question

When the frame leaves the router, how much of it has changed?

What I found

Very little. For plain IPv4 routing, four things change:

#	What changes	Why
1	TTL goes down by 1 (for example, 64 becomes 63)	Required by RFC 1812, so a packet caught in a routing loop cannot circulate forever
2	IPv4 header checksum is updated	The checksum covers the TTL, so the old value no longer matches
3	New Ethernet header	Destination MAC = next hop, source MAC = router's outgoing interface. MACs change at every hop; IP addresses do not
4	New FCS	It covers the new header, so it must be calculated again

Not touched in plain routing: the source and destination IP addresses, the TCP header, and your data.

A detail in edit 2: the book says the IPv4 header checksum "needed to be recomputed at every router" (section 4.3.5). Linux does not re-add the whole header; it updates the checksum incrementally (include/net/ip.h):

static inline
int ip_decrease_ttl(struct iphdr *iph)
{
    u32 check = (__force u32)iph->check;
    check += (__force u32)htons(0x0100);
    iph->check = (__force __sum16)(check + (check>=0xFFFF));
    return --iph->ttl;
}

TTL is the high byte of a 16-bit header word (TTL + Protocol), so lowering TTL by 1 lowers that word by 0x0100. The checksum is the ones' complement of the sum, so it goes up by 0x0100; check + (check>=0xFFFF) handles the end-around carry. RFC 1812 (section 4.2.2.5) allows this incremental update, and RFC 1624 describes the method.

Exceptions worth knowing

NAT: a home router doing NAT also changes the source IP address and port, and with them the IP and TCP/UDP checksums.
Fragmentation: in IPv4, a router may split a packet that is too large for the next link (see Part 3).
QoS and congestion marks: some routers rewrite the DSCP value or set the ECN bits in the IP header.
IPv6 is simpler: the Hop Limit replaces the TTL, there is no header checksum (RFC 8200), and routers never fragment IPv6 packets; only the source does. So an IPv6 router makes three of the four edits.

TTL and traceroute

When the TTL runs out, RFC 1812 says the router must drop the packet and send ICMP Time Exceeded to the source. traceroute relies on this: its man page says it starts its probes "with a ttl of one and increase[s] by one" and listens for the Time Exceeded replies. Each reply reveals one router's address on the path.

Not every router answers. Linux rate-limits these ICMP messages by default (net.ipv4.icmp_ratelimit and net.ipv4.icmp_ratemask), and some networks filter them. That is one reason traceroute sometimes shows * * * for a hop.

Key idea

The router keeps your packet and rebuilds the frame around it. The IP packet inside changes in only two small fields (TTL and checksum), unless NAT or another feature is involved.

Part 5: The Cost: N × L/R

The question

If every router waits for the whole packet, how does the waiting add up across a path?

What I found

The book (section 1.3.1, equation 1.1) gives the delay for one packet over N links of rate R, with N - 1 routers in between:

d(end-to-end) = N × L / R

This ignores propagation, queuing and processing delay. Each link adds one full L/R, because each router waits for the last bit.

Example (same round numbers, three links):

3 × 12,000 bits / 100 Mbps = 3 × 120 µs = 360 µs

Where this fits among the four delays

Section 1.4.1 of the book splits the delay at each node into four parts:

Delay	What it is	Typical size (book)
Processing	Examine the header, decide where to send it, check for bit errors	microseconds or less in high-speed routers
Queuing	Wait behind other packets for the output link	microseconds to milliseconds, depends on traffic
Transmission	Push all bits onto the link: L/R	microseconds to milliseconds
Propagation	Travel time along the link: distance / speed	milliseconds in wide-area networks

Store-and-forward makes the transmission delay repeat at every hop; the other three come on top.

Transmission and propagation are easy to mix up. A made-up example: on a 1,000 km fiber link, signals travel at about 2 × 10⁸ m/s (the book gives 2 × 10⁸ to 3 × 10⁸ m/s), so propagation takes 1,000,000 m ÷ (2 × 10⁸ m/s) = 5 ms. Pushing our 1500-byte packet onto that link at 100 Mbps takes 120 µs. Transmission depends on packet size and link rate; propagation depends on distance.

Compare circuit switching (book, section 1.3.2): with a reserved end-to-end circuit, "the transmission time is independent of the number of links". Packet switching pays per hop instead, and in return the links are shared.

Key idea

Store-and-forward makes the L/R delay repeat on every link. On top of it come processing, queuing and propagation.

Part 6: Why Your Data Is Cut Into Small Packets

The question

If every hop waits for the whole packet, what happens when a packet is very large?

What I found

The wait grows with L. Smaller packets let the links work at the same time: while packet 1 is on link 2, packet 2 is already on link 1. This is called pipelining.

The book's example: three packets, one router. The destination has all three after 4L/R, not 6L/R. The book leaves the general case (P packets, N links) as an exercise. By the same reasoning, the first packet arrives after N × L/R and each further packet one L/R later:

d = (N + P - 1) × L / R

Example (same 3 links at 100 Mbps, 1.5 MB to send, headers ignored):

How it is sent	Calculation	Time
One imaginary 1.5 MB packet	3 × (12,000,000 bits / 100 Mbps)	360 ms
1000 packets of 1500 bytes	(3 + 1000 - 1) × 120 µs	≈ 120 ms

The 1.5 MB packet is imaginary: the 16-bit IPv4 Total Length field caps a packet at 65,535 bytes, and the usual 1500-byte Ethernet MTU allows at most 1500 bytes of IP packet per frame.

With real headers: a 1500-byte IPv4/TCP packet without options carries 1460 bytes of data (1500 - 20 - 20). Sending 1,500,000 bytes then takes 1028 packets: (3 + 1028 - 1) × 120 µs ≈ 123.6 ms (Ethernet framing still ignored, as in Part 1). Same conclusion.

Small packets have a cost too: each one carries its own headers, so very small packets spend more of the link on headers, and each one costs the router some processing. The book's end-of-chapter problems P31 and P33 explore this trade-off, with and without header overhead.

Key idea

Cutting data into packets lets the links of a path work in parallel. The store-and-forward wait then applies to one small packet at a time instead of the whole message.

Part 7: Not Every Box Waits

The question

Does every network device store and forward?

What I found

The book describes both routers and Ethernet switches as store-and-forward packet switches (sections 1.3.1 and 6.4.2), and the Linux path above is store-and-forward too.

Some Ethernet switches use a shortcut called cut-through: they start sending a frame as soon as they have read the destination address and chosen the output port. The destination MAC is the first field of the Ethernet header, so this can happen long before the frame has fully arrived. The trade-off:

	Store-and-forward	Cut-through
Starts sending	After the whole frame has arrived	After the destination address is read
FCS checked before sending	Yes	No, the end has not arrived yet
Damaged frame	Dropped at this switch	Can be passed on to the next device
Delay added	At least L/R per hop	Lower: it does not wait for the rest of the frame

A cut-through switch must still buffer a frame when the output port is busy with another frame, or when the output port is faster than the input port (otherwise it would run out of bits to send).

Key idea

Store-and-forward trades a little delay for a check on every hop. Cut-through trades that check for lower delay. Routers, as described in the book and implemented in Linux, store and forward.

Summary

Store-and-forward in three lines:

Why it waits: the FCS sits at the end of the frame, and RFC 1812 requires a valid IP header checksum before processing.
What it changes: TTL, header checksum, Ethernet header and FCS, and nothing else in plain IPv4 routing.
What it costs: one L/R per link, which is why data travels as many small packets.

One detail stands out: the book says the checksum is recomputed at every router, but ip_decrease_ttl() shows it can be a small incremental update instead of a full recalculation.

References

Kurose, J. & Ross, K., Computer Networking: A Top-Down Approach, 7th ed.: sections 1.3.1 (store-and-forward, equation 1.1), 1.3.2 (circuit switching example), 1.4.1 (four types of delay), 4.3.1 (IPv4 datagram format), 4.3.5 (IPv6), 6.4.2 (Ethernet frame and CRC); end-of-chapter problems P31 and P33 (chapter 1)
RFC 1812: Requirements for IP Version 4 Routers (sections 4.2.2.5, 5.2.2, 5.3.1)
RFC 1624: Computation of the Internet Checksum via Incremental Update
RFC 791: Internet Protocol
RFC 792: Internet Control Message Protocol
RFC 8200: Internet Protocol, Version 6 (IPv6) Specification
Linux source (mainline 7.3): drivers/net/ethernet/realtek/r8169_main.c, net/ipv4/ip_forward.c, net/ipv4/ip_input.c, net/ipv4/ip_output.c, net/ipv4/route.c, include/net/ip.h, include/net/neighbour.h, include/linux/etherdevice.h, include/linux/skbuff.h, net/ethernet/eth.c
Linux kernel documentation: IP sysctl (icmp_ratelimit, icmp_ratemask), netdev features (rx-fcs, rx-all)
Docker documentation: Packet filtering and firewalls (IP forwarding)
Wikipedia: Cut-through switching, which cites Cisco's white paper Cut-Through and Store-and-Forward Ethernet Switching for Low-Latency Environments (C11-465436)
Man pages: ip-link(8), nstat(8), ethtool(8), traceroute(8) (traceroute 2.1.6)

Learning TCP/IP From the Linux Side: Spec, Code, and Wire

Musa Nayyer — Tue, 13 Oct 2026 19:47:52 +0000

My networking notes used to be full of layer names, header diagrams, and TCP flags. I knew the terminology, but when someone asked what happens after calling send(), my explanation stopped at "the data goes down the stack."

I changed my approach by connecting three things:

The spec: what the RFC defines.
The code: how Linux or C headers represent it.
The wire: what tcpdump or Wireshark captures.

This post applies that approach to four exercises, moving from packet construction to TCP security.

From application data to the network
Layer 2 vs Layer 3
One TCP header, three views
How TCP validates RST packets

The commands are generally safe on a normal Linux machine. Commands requiring elevated privileges are identified.

Part 1: From Application Data to the Network

The question

When an application sends bytes, which components add the headers, and where are those headers represented in memory?

What I found

When an application calls send() or write() on a TCP socket, the operation enters the kernel. The networking stack processes the data using structures such as sk_buff, defined in include/linux/skbuff.h.

An sk_buff can provide space before packet data (headroom) and after it (tailroom). Networking layers can use this space to add headers without necessarily copying the payload into a new buffer at every layer.

Step	Who does it	What gets added
1	Application	Payload (your bytes)
2	TCP	TCP header, 20 bytes minimum (more with options)
3	IP	IP header, 20 bytes for IPv4 without options
4	Ethernet / neighbor layer	14 byte Ethernet header (MACs + EtherType)
5	NIC driver	Hands the buffer to the card, usually through DMA
6	NIC hardware	Adds the FCS (CRC) and puts bits on the medium

SA typical Ethernet frame looks like this:

[ Ethernet ][ IP ][ TCP ][ payload ][ FCS ]

The exact operations depend on the networking path and enabled features.

Why it matters

Headroom: insufficient space may require the kernel to expand or reallocate the buffer.
FCS: normal host captures often omit it because the NIC adds it after the capture point.
Offloads: checksum and segmentation offloads can make captured packets differ from their final on-wire form.

The packet diagram describes the format; the kernel and NIC determine how it is constructed and transmitted.

Part 2: Layer 2 vs Layer 3, Seen From Linux

The question

If IP addresses identify hosts, why do we also need MAC addresses?

What I found

They serve different purposes:

	Layer 2 (Ethernet)	Layer 3 (IP)
Address	MAC address	IP address
Scope	One local link	End to end, across networks
Unit	Frame	Packet
Device	Switch	Router
Linux command	`ip neigh`	`ip route`

The via field identifies the selected next hop.

Next, inspect neighbor mappings:

ip neigh show

Example:

192.168.1.1 dev wlan0 lladdr aa:bb:cc:dd:ee:01 REACHABLE

On IPv4 Ethernet networks, ARP commonly resolves an IP address to a MAC address.

Capture the traffic to inspect both layers:

sudo tcpdump -n -e -i wlan0 host 203.0.113.20

The -e option displays link-layer information. For traffic routed through the gateway, the Ethernet destination MAC should correspond to the gateway, while the IP destination remains 203.0.113.20.

The distinction: ip route reveals the next-hop decision; ip neigh helps identify the corresponding link-layer address.

Part 3: One TCP Header, Three Views

The question

Does the TCP header diagram in a textbook correspond to what the kernel and tcpdump actually use?

View 1: The spec

The current base TCP specification is RFC 9293 (2022), which obsoleted the original RFC 793. The header format is described in section 3.1:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
|                        Sequence Number                        |
|                    Acknowledgment Number                      |
| Offset| Rsrvd |   Flags       |            Window             |
|           Checksum            |         Urgent Pointer        |
|                    Options (variable length)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Each row represents 32 bits. The flags are CWR ECE URG ACK PSH RST SYN FIN.

View 2: The code

On Linux systems using glibc, the TCP header is declared in <netinet/tcp.h> as struct tcphdr. A shortened representation looks like this:

struct tcphdr {
    uint16_t source;
    uint16_t dest;
    uint32_t seq;
    uint32_t ack_seq;
    uint16_t doff:4;   /* data offset */
    uint16_t syn:1;
    /* ... other flag bits ... */
    uint16_t window;
    uint16_t check;
    uint16_t urg_ptr;
};

The actual declaration includes additional flags and handles bit-field ordering according to byte order. Linux also has kernel-side TCP definitions, and other systems may use different field names.

The fields map to the RFC concepts: doff is the data offset, check the checksum, and urg_ptr the urgent pointer.

View 3: The wire

Capture TCP traffic on port 443:

sudo tcpdump -n -S -i any tcp port 443

-n displays numeric addresses and ports instead of resolving names.
-S displays absolute sequence numbers rather than relative ones.

A SYN packet might appear like this:

IP 192.0.2.10.51514 > 198.51.100.20.443: Flags [S], seq 1520943817, win 64240, options [mss 1460,...], length 0

The displayed fields can now be related to the C declaration and the RFC:

tcpdump	struct tcphdr	RFC 9293
`51514`	`source`	Source Port
`443`	`dest`	Destination Port
`seq 1520943817`	`seq`	Sequence Number
`Flags [S]`	`syn`	SYN flag
`win 64240`	`window`	Window
`options [mss 1460]`	follows `doff`	Options

Common flag notation includes [S] for SYN, [S.] for SYN+ACK, [P.] for PSH+ACK, [F.] for FIN+ACK, and [R] for RST.

The checksum gotcha

When I first ran tcpdump -v on the sending host, some outgoing packets appeared to have incorrect TCP checksums.

A common cause is checksum offload. The kernel may leave checksum calculation to the NIC, while the capture occurs before the final checksum is written. The packet can therefore appear invalid in the capture even though the NIC calculates the correct checksum for transmission.

You can inspect the relevant interface features with:

ethtool -k wlan0 | grep checksum

The capture point matters: captured packets may not yet reflect their final on-wire representation.

Part 4: How TCP Knows an RST Is Legitimate

The question

An RST can terminate a TCP connection. How does the receiver decide whether to accept one?

Sequence numbers as a defense

TCP tracks bytes using sequence numbers. Two relevant receiver variables are:

RCV.NXT: the next sequence number expected.
RCV.WND: the receive window, describing the currently acceptable sequence-number range.

Under the original RFC 793 rules, an RST could be accepted if its sequence number fell within the receive window. A blind attacker therefore did not necessarily need to guess the exact expected number.

RFC 5961 tightened the check

RFC 5961, section 3, introduced stricter RST validation. Suppose RCV.NXT = 5000 and the receive window is 1000.

RST seq	Where it falls	What the receiver does
`5000`	Exactly `RCV.NXT`	Reset the connection
`5400`	Inside the window, not exact	Send a challenge ACK, keep the connection
`9000`	Outside the window	Drop it silently

Instead of immediately accepting an in-window RST with a non-exact sequence number, the receiver sends a challenge ACK reflecting its current TCP state.

This makes blind, off-path reset attacks harder because the attacker must produce a more precise packet without observing the connection. The sequence-number space contains (2^{32}), or about 4.29 billion, possible values, although real security also depends on protocol state, window size, implementation details, and the attacker's information.

Checking it on Linux

Linux implements challenge-ACK handling. You can inspect the corresponding counter with:

nstat -az TcpExtTCPChallengeACK

Related settings include:

sysctl net.ipv4.tcp_challenge_ack_limit
sysctl net.ipv4.tcp_invalid_ratelimit

CVE-2016-5696 demonstrated that Linux's shared challenge-ACK rate limit could leak information useful for inferring TCP connection state. Subsequent kernel changes addressed this side channel by changing how the limit was applied.

This illustrates why security mechanisms must also be assessed for information leaks introduced by their implementations.

What to look for in Wireshark

Filter resets with tcp.flags.reset == 1.
Disable relative sequence numbers or add tcp.seq_raw to inspect raw values.
Compare the RST sequence number with the receiver's expected sequence.
Look for a challenge ACK following an in-window RST that fails the stricter check. Wireshark's analysis labels depend on the observed exchange.

An RST followed by an ACK while the connection continues may be consistent with challenge-ACK handling, but the surrounding packets are needed to establish what happened.

Blind vs on-path attackers

Blind (off-path): cannot observe the connection's traffic and must infer or guess sequence numbers. RFC 5961 makes certain blind reset attacks significantly harder.
On-path: can observe traffic and may know the relevant sequence numbers. Sequence-number checks alone do not authenticate against this attacker.

For deployments needing TCP-level authentication, TCP Authentication Option (TCP-AO), defined in RFC 5925, can authenticate segments using a shared key. A forged RST lacking the required authentication value should fail validation when TCP-AO is correctly configured and enforced.

TCP-AO succeeds the older TCP MD5 signature option (RFC 2385), is relevant to sessions such as BGP, and gained Linux kernel support in version 6.7.

TLS does not solve this problem: TCP handles connection resets below the TLS layer, so TLS alone does not authenticate TCP RST packets.

Key idea

Sequence-number checks help defend against blind attackers. When protection against attackers who can observe the traffic is required, TCP-level authentication, such as TCP-AO where supported and configured, addresses a different part of the threat model.

What Changed in How I Learn

These exercises exposed gaps in my earlier notes. I knew an RST terminates a connection, but had not investigated how TCP decides to accept one. I understood the difference between IP and MAC addresses, but had not examined a packet where the two destinations referred to different machines.

The method is straightforward:

Read the RFC: focus on the relevant section.
Find the implementation: inspect a C header, kernel source file, or sysctl.
Observe the behavior: use tcpdump, Wireshark, ip, ss, or nstat.
Investigate differences: unexpected output can reveal details about the implementation or capture point.

Connecting the specification, implementation, and observed traffic gives you a practical way to test and deepen your understanding.

References

RFC 9293: Transmission Control Protocol (TCP)
RFC 5961: Improving TCP's Robustness to Blind In-Window Attacks
RFC 5925: The TCP Authentication Option
RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature Option
Linux source: include/linux/skbuff.h, net/ipv4/tcp_input.c
glibc: <netinet/tcp.h>
man 8 ip-route, man 8 ip-neighbour, man 8 tcpdump, man 8 nstat

Containers Are Isolated, But They Still Share the Kernel

Musa Nayyer — Wed, 07 Oct 2026 19:49:11 +0000

Namespaces, capabilities, seccomp, and two 2026 kernel vulnerabilities that show where Docker isolation ends

Containers are lightweight because they do not run their own kernel.

They can have their own filesystem, process tree, network stack, and other isolated resources, but underneath all of that, containerized processes still use the host Linux kernel.

That one fact is extremely important for container security.

In 2026, two Linux kernel vulnerabilities made this boundary particularly interesting:

CVE-2026-31431 ("Copy Fail") showed how a vulnerable kernel interface reachable from a container could affect resources outside that container.
CVE-2026-80521 demonstrated a container escape involving the Linux kernel's AF_UNIX subsystem.

This does not mean Docker is unsafe or that containers should not be used.

The important lesson is simpler:

Container isolation is ultimately enforced by the host kernel.

Understanding that boundary helps explain both the strengths and limitations of container security.

Containers Are Not Small Virtual Machines

A virtual machine runs its own guest operating system and its own kernel.

A container does not.

A container is better understood as a group of Linux processes running with restricted views and permissions provided by the kernel.

Those processes still make system calls to the host kernel.

This is one of the reasons containers are so lightweight. There is no separate guest kernel to boot for every container.

But it also creates an important security relationship:

The host Linux kernel is part of the trusted computing base for containers.

If a kernel vulnerability allows an attacker to bypass one of the mechanisms enforcing isolation, the container boundary can potentially be weakened or crossed.

Virtual machines are not completely immune to this problem either. Hypervisors have also had escape vulnerabilities.

The broader principle is that every isolation mechanism has a trusted computing base.

For conventional containers, a particularly important part of that trusted base is the Linux kernel.

What Actually Isolates a Container?

Docker uses several Linux security mechanisms. The most important ones include:

Namespaces
cgroups
Capabilities
seccomp
AppArmor or SELinux
User namespaces

Each solves a different problem.

Namespaces: What Can the Process See?

Linux namespaces provide processes with isolated views of system resources.

For example:

Namespace	Main purpose
PID	Process visibility
Mount	Filesystem mount view
Network	Network interfaces and ports
UTS	Hostname
IPC	Inter-process communication
User	User and group ID mappings
Cgroup	Cgroup hierarchy view
Time	Certain process-visible clocks

A simple way to remember namespaces is:

Namespaces control what a process can see.

A container can therefore have its own process list, filesystem view, and network environment even though those resources ultimately exist on the same kernel.

cgroups: How Much Can It Use?

Control groups, or cgroups, deal with resource management.

They can control or account for resources such as:

CPU
Memory
Number of processes
I/O

So the basic mental model is:

Namespaces
    ↓
What can this process see?

cgroups
    ↓
How much can this process use?

These mechanisms complement each other rather than solving the same problem.

Capabilities: What Privileged Operations Are Allowed?

Linux does not treat root as one giant permission.

Instead, many privileged operations are divided into capabilities.

Examples include:

CAP_NET_ADMIN
CAP_SYS_ADMIN
CAP_SYS_MODULE
CAP_SYS_PTRACE

Docker normally starts containers with a reduced set of capabilities.

That means a process can have UID 0 — effectively "root" inside the container — without automatically having every privileged operation available to host root.

Administrators can also explicitly add or remove capabilities:

--cap-add
--cap-drop

For application containers, dropping capabilities that are not required is generally preferable to giving the container additional privileges.

User Namespaces: Is Container Root Also Host Root?

User namespaces can map the container's UID 0 to an unprivileged UID on the host.

Conceptually:

Container
UID 0
  ↓
Host
UID 100000

Docker supports this through user namespace remapping, and rootless Docker provides another approach to reducing host-level privilege.

However, these protections depend on configuration.

On a normal Docker configuration without user namespace remapping, UID 0 inside the container can map directly to UID 0 on the host.

That does not mean the container automatically has unrestricted host access. Other controls such as capabilities, namespaces, seccomp, and LSM policies still apply.

But it does mean there is no additional UID-remapping boundary in that configuration.

seccomp: Which System Calls Can the Container Make?

A containerized application constantly interacts with the kernel through system calls.

seccomp can filter these calls.

Conceptually:

Container process
       |
       | system call
       ↓
   seccomp filter
      /      \
   ALLOW    DENY
      |
      ↓
 Linux kernel

Docker's default seccomp profile restricts access to a number of system calls.

This is useful because reducing the available system-call surface can make some kernel vulnerabilities harder to reach.

But there is an important limitation:

seccomp is not a complete sandbox.

It reduces the kernel interface available to a process. It does not make the remaining kernel code vulnerability-free.

That distinction becomes especially important when looking at real kernel vulnerabilities.

AppArmor and SELinux

Linux Security Modules, or LSMs, provide another layer of mandatory access control.

On systems using AppArmor, Docker can apply profiles such as docker-default.

Other distributions commonly use SELinux.

The overall security model therefore looks roughly like this:

Notice where the model ends:

the Linux kernel.

The kernel ultimately enforces these isolation mechanisms.

That is why kernel vulnerabilities can become container-security problems.

Case Study 1: Copy Fail — CVE-2026-31431

One useful example is CVE-2026-31431, known as "Copy Fail."

The vulnerability affected the Linux kernel's algif_aead component of the AF_ALG userspace cryptographic interface.

The important point for containers is not simply that the kernel contained a vulnerability.

It is that a default container could reach the vulnerable interface.

At a high level:

Container
    ↓
AF_ALG interface
    ↓
Linux kernel
    ↓
algif_aead
    ↓
CVE-2026-31431

According to Docker's technical analysis, the vulnerability could allow an unprivileged user with access to an AF_ALG socket to perform controlled writes to the page cache.

The page cache is a kernel-managed resource rather than something isolated per container.

That means the consequences are not necessarily limited to the container in which the vulnerable code executes.

The Important Concept: Reachability

This is one of the most useful ideas in container security.

A vulnerable kernel function is not automatically reachable from every container.

The practical question is:

Is vulnerable code present?
        ↓
Can the container reach it?
        ↓
Can the attacker trigger it?
        ↓
What resources can be affected?

For Copy Fail, the relevant interface was AF_ALG.

Docker therefore introduced additional security-profile restrictions to reduce container access to that interface.

But there is an important distinction:

A Docker security-profile mitigation does not repair vulnerable kernel code.

A kernel update fixes the underlying vulnerability.

A security-profile change can instead reduce the ability of containers to reach the vulnerable functionality.

Both approaches can be valuable.

Case Study 2: CVE-2026-80521 and AF_UNIX

A second example is CVE-2026-80521, involving the Linux kernel's AF_UNIX subsystem.

AF_UNIX sockets are widely used for local inter-process communication.

The published research described a use-after-free involving the kernel's AF_UNIX garbage-collection mechanism and demonstrated a container escape.

This example is interesting for a different reason.

AF_ALG is a relatively specialized interface.

AF_UNIX, on the other hand, is deeply integrated into normal Linux applications.

That creates a different defensive challenge.

You can potentially block access to a specialized interface.

It is much harder to remove access to a kernel subsystem that ordinary applications depend on.

A necessary distinction

It would be misleading to summarize this as:

"Containers can always be escaped."

That is far too broad.

A more accurate statement is:

A kernel vulnerability in functionality reachable from a container can potentially undermine the isolation mechanisms that container runtimes depend on.

Whether a particular system is exploitable depends on factors such as:

Kernel version
Whether the vulnerable code is present
Whether the relevant interface is reachable
Container configuration
Capabilities
seccomp
LSM policies
User namespace configuration
Available mitigations

So the vulnerability demonstrates a limitation of shared-kernel isolation. It does not mean every container on every Linux system is automatically vulnerable.

What Does "Container Escape" Actually Mean?

A container escape occurs when code running inside a container gains access beyond the intended container boundary.

Depending on the vulnerability and configuration, that could mean access to:

Host files
Host processes
Host kernel resources
The container runtime
Other workloads

Conceptually:

NORMAL

Container A  ──X──> Host
Container A  ──X──> Container B


AFTER A SUCCESSFUL ESCAPE

Container A ───────> Host
                       ├── Host filesystem
                       ├── Host processes
                       ├── Container runtime
                       └── Other workloads

"Escape" is not one fixed outcome.

The actual impact depends heavily on the host configuration and what the attacker can access after crossing the intended boundary.

That is why saying simply "the container was escaped" does not tell the entire story.

A Small Hands-On Demonstration

I tested several of these concepts on my own CachyOS system using:

CachyOS
Linux kernel 7.2.7-1-cachyos
Docker Engine 29.8.2

The following demonstrations do not exploit a vulnerability. They simply show how container isolation works.

Check Docker's Security Configuration

docker info --format "{{.SecurityOptions}} cgroup v{{.CgroupVersion}}"

My system reported:

[name=seccomp,profile=builtin name=cgroupns] cgroup v2

This showed that Docker was using its built-in seccomp profile and cgroup namespaces.

AppArmor was not enabled on this system.

That is an important reminder:

Container security depends partly on the host configuration.

Compare Container and Host Processes

Start a container:

docker run -d --rm --name nslab alpine sleep 30

Then inspect the process from the host:

ps -o user,pid,cmd -C sleep

The host can see the process.

Inside a normal container, however:

docker run --rm alpine ps

the container sees its own PID namespace rather than the host's complete process list.

This is a simple demonstration of what namespaces actually provide:

the process still exists on the host, but the container has a restricted view of it.

See What Happens With `--privileged`

Now compare a normal container with a privileged container:

docker run --rm --privileged alpine \
  sh -c 'grep -E "^(CapEff|NoNewPrivs|Seccomp)" /proc/self/status'

A privileged container receives substantially broader privileges and disables the normal seccomp restrictions shown in the test.

This illustrates an important point:

"It runs in a container" does not tell you the security posture of that container.

You also need to know how it was configured.

Kubernetes: The Same Kernel Boundary Still Exists

Kubernetes does not create a second kernel for every Pod.

Pods ultimately run through a container runtime on a node and therefore share that node's Linux kernel.

However, Kubernetes security settings can significantly change the isolation provided to workloads.

For example, Kubernetes supports explicitly requesting the runtime's default seccomp profile:

spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault

Other settings worth paying attention to include:

hostPID
hostNetwork
hostIPC
hostPath
privileged

These features can intentionally weaken parts of the normal isolation model.

So instead of asking:

"Does Kubernetes isolate my container?"

a better question is:

"Which isolation mechanisms are actually enabled for this workload and this node?"

Practical Hardening

The goal is not to make containers impossible to use.

The goal is to reduce unnecessary privileges and keep the underlying host secure.

Host

Keep the host kernel patched.
Reboot when an updated kernel needs to become active.
Follow your distribution's security advisories.
Stay on a supported kernel series.

Docker

Keep Docker Engine updated.
Avoid --privileged for ordinary workloads.
Drop unnecessary capabilities.
Run applications as non-root users where possible.
Consider no-new-privileges.
Keep the default seccomp profile enabled.
Avoid seccomp=unconfined unless there is a documented reason.
Consider rootless Docker or user namespace remapping.
Avoid mounting /var/run/docker.sock unless it is genuinely required.

Kubernetes

Use seccompProfile: RuntimeDefault.
Consider enabling seccompDefault.
Use runAsNonRoot: true.
Set allowPrivilegeEscalation: false where appropriate.
Drop unnecessary capabilities.
Avoid privileged containers.
Avoid unnecessary host namespace sharing.
Keep worker-node kernels patched.

What About Untrusted Workloads?

Not every workload needs the same isolation strength.

A normal web application running in a container has a different threat model from:

Multi-tenant infrastructure
Customer-submitted code
Untrusted CI jobs
Generated-code execution
Security research sandboxes

For highly untrusted workloads, stronger isolation technologies may be appropriate.

Examples include:

Firecracker
Kata Containers
gVisor

These approaches introduce their own trade-offs in complexity, compatibility, and performance.

The goal is not to declare containers obsolete.

The goal is to choose an isolation boundary appropriate for the workload.

What Defenders Can Actually Monitor

Patching is the first line of defense.

Detection is useful when prevention fails or when someone changes the security configuration unexpectedly.

On container hosts, useful signals can include unexpected:

setns
unshare
Mount operations
Kernel module loading
Access to container runtime sockets
Privileged processes
Changes to sensitive host files

In Kubernetes, defenders can also watch for unexpected:

privileged: true
hostPID
hostNetwork
hostIPC
hostPath
Capability additions
Suspicious kubectl exec
Changes to Pod security settings

Useful evidence sources include:

auditd
journald
Container runtime logs
Kubernetes audit logs
Kernel logs
eBPF-based runtime telemetry

Tools such as Falco and Tetragon can also provide runtime visibility into process and syscall activity.

For container escapes, node-level visibility is particularly important because the boundary being attacked is ultimately enforced by the node's kernel.

Conclusion

Containers remain one of the most useful ways to package and run software.

The important security lesson is not that containers are inherently unsafe.

It is that their isolation is implemented through kernel mechanisms.

The simplified model is:

Application
    ↓
Container configuration
    ↓
Capabilities / user identity
    ↓
seccomp / AppArmor / SELinux
    ↓
Linux kernel
    ↓
Hardware / virtualization boundary

The 2026 vulnerabilities discussed here illustrate two different sides of that boundary.

CVE-2026-31431 (Copy Fail) showed how restricting access to a vulnerable kernel interface can reduce container exposure.

CVE-2026-80521 demonstrated the harder case: when vulnerable functionality belongs to a subsystem that ordinary applications depend on, completely removing access to that functionality may not be practical.

The practical defense is therefore layered:

Reduce container privileges.
Restrict unnecessary kernel interfaces.
Use seccomp and LSM policies.
Keep the host kernel patched.
Monitor the node, not only the application.
Use stronger isolation when the workload is genuinely untrusted.

And the key idea to remember is simple:

A container can isolate an application from the host only as well as the kernel enforcing that isolation.

# LibreWolf Stopped Playing Videos After the FFmpeg 9 Update

Musa Nayyer — Wed, 30 Sep 2026 14:21:18 +0000

After a recent system update on Arch Linux, video playback in LibreWolf suddenly stopped working.

At first, it wasn't obvious what had changed. I went through the usual possibilities, including hardware acceleration, VPN/DNS issues, browser cache, and other playback-related settings.

Eventually, the timing pointed toward an FFmpeg update.

The Problem

LibreWolf was no longer able to play videos correctly after the system update.

The browser reported:

NS_ERROR_DOM_MEDIA_METADATA_ERR

The important part was that normal browsing still worked. The failure was specific to media playback.

That left several possible places to investigate.

What I Tried

I started with the usual browser-side checks.

I checked hardware acceleration and browser-related settings to make sure the problem wasn't caused by a configuration change inside LibreWolf.

I also looked at the VPN and DNS configuration because the problem initially happened while the VPN was being used.

The OpenVPN logs showed:

Initialization Sequence Completed

So the VPN connection itself was completing successfully.

There was also a resolvconf warning:

resolvconf: signature mismatch: /etc/resolv.conf

I checked the resolver state and manually ran:

sudo resolvconf -u

That completed without producing the previous lock error, but it did not fix LibreWolf's media playback.

At that point, the network configuration was looking less likely to be the cause.

What I Found

The investigation eventually moved toward the multimedia libraries used by LibreWolf.

The important change in the system update was an FFmpeg major-version update from 8 to 9.

That timing stood out because FFmpeg major releases can involve changes to the libraries applications depend on. If an application or package hasn't been updated for the new library interface yet, compatibility problems can occur.

That matched what I was seeing.

The problem was no longer looking like a VPN, DNS, browser-cache, or ordinary browser-settings issue.

The FFmpeg update provided a much stronger lead.

The Compatibility Problem

The evidence pointed toward a compatibility problem between the updated FFmpeg libraries and the LibreWolf build installed on my system.

The important distinction is that this does not mean that FFmpeg 9 itself was broken.

The problem was the transition between major library versions and whether the application using those libraries was ready for that change.

In my case, the installed LibreWolf package had not yet caught up with the transition.

The Workaround

I tested the compatibility theory by installing the older FFmpeg compatibility package:

sudo pacman -S ffmpeg4.4

The ffmpeg4.4 package provides the older FFmpeg 4.4 libraries alongside the current FFmpeg package.

After installing it, LibreWolf was able to play videos again.

That gave me a much stronger connection between the FFmpeg transition and the playback failure.

Verification

The verification was simple.

I opened the same video that had previously failed.

After installing ffmpeg4.4, playback worked again.

That made the compatibility explanation much more convincing than the earlier theories around VPN, DNS, hardware acceleration, or browser cache.

The important sequence was:

FFmpeg update
      ↓
LibreWolf media playback fails
      ↓
ffmpeg4.4 installed
      ↓
Media playback works again

This was also consistent with a recent Arch Linux forum report from August 2026 where LibreWolf video playback broke after the FFmpeg 8 → 9 update and ffmpeg4.4 was used as a temporary workaround until a LibreWolf update resolved the issue.

Trade-offs

ffmpeg4.4 is a workaround, not necessarily the permanent solution.

The better long-term solution is for the affected application/package to support the newer FFmpeg libraries.

That means the compatibility package may no longer be necessary once LibreWolf and its dependencies have caught up with the newer FFmpeg version.

I would therefore treat the older package as a temporary compatibility measure rather than something that should automatically be kept forever.

What I Learned

A major multimedia-library update can break an application even when the application itself appears to be working normally.

The useful clue here was the timing.

Video playback stopped working immediately after a significant system-library update, while the rest of the browser continued working.

That made the changed multimedia libraries worth investigating.

The troubleshooting path ended up looking like this:

Media playback failure
        ↓
Browser settings checked
        ↓
VPN/DNS checked
        ↓
Network issue became less likely
        ↓
FFmpeg major update noticed
        ↓
Compatibility tested
        ↓
ffmpeg4.4 restored playback

The error initially looked like a browser media problem.

The actual investigation led underneath the browser, into the system multimedia libraries it depended on.

If You Hit Something Similar

If LibreWolf or another application suddenly stops playing media after an Arch Linux update, check:

The exact media error
Recent package upgrades
FFmpeg version changes
Browser and multimedia-library dependencies
Hardware-acceleration settings
Whether the problem occurs with different media sources
Whether a newer application build is available

The package-update history can be especially useful when the failure starts immediately after a system upgrade.

Don't keep changing browser settings indefinitely if the problem started at exactly the same time as a major dependency update.

Check what changed underneath the application.

Environment

The relevant environment during testing was:

OS: CachyOS
Browser: LibreWolf
Session: Wayland
Desktop: KDE Plasma 6
FFmpeg: 8 → 9 transition
Compatibility package tested: ffmpeg4.4

Your exact behavior may differ depending on your LibreWolf version, FFmpeg version, package source, and system configuration.

Final Takeaway

The problem initially looked like a LibreWolf media error.

The timing of the failure pointed toward the FFmpeg 8 → 9 transition.

Installing ffmpeg4.4 restored video playback on my system, which provided a practical compatibility workaround.

I would treat that as a temporary measure rather than a permanent fix. Once the affected LibreWolf package supports the newer FFmpeg libraries correctly, the compatibility package should no longer be necessary.

Sources

KWin Crashed Every Time I Fullscreened Edge on My Second Monitor: Direct Scanout Was the Culprit

Musa Nayyer — Wed, 23 Sep 2026 18:09:41 +0000

KWin Crashed Every Time I Fullscreened Edge on My Second Monitor: Direct Scanout Was the Culprit

I ran into a reproducible KWin Wayland crash that happened whenever I fullscreened Microsoft Edge on my secondary monitor.

The strange part was that the monitor itself wasn't disconnecting. The screen briefly went black, KWin crashed, and the desktop came back as if a new display had been connected.

After narrowing down the symptoms, I traced the crash to KWin's direct-scanout path.

The workaround was to disable direct scanout.

The Setup

This happened on a Linux desktop running:

CachyOS
KDE Plasma 6
Wayland
Hybrid AMD/NVIDIA graphics
Microsoft Edge
Two monitors

The secondary display was connected through HDMI and was running at 1920×1080 around 60 Hz.

The primary display was running at a much higher refresh rate.

The problem only appeared when I fullscreened Edge on the secondary monitor.

What Happened

The first thing I noticed was confusing.

I would fullscreen an Edge window on the second monitor and the display would suddenly go black for about a second.

Then KDE recovered and showed a notification that a new display had been detected.

At first, this looked like a display or GPU issue.

But the monitor itself hadn't actually disconnected.

KWin was crashing, restarting, and detecting the displays again.

That distinction turned out to be important.

Reproducing the Crash

The crash was surprisingly consistent.

The sequence was roughly:

Open Microsoft Edge.
Move the window to the secondary monitor.
Enter fullscreen.
The secondary display goes black.
KWin crashes.
The desktop recovers.
KDE reports that a display was detected again.

I could repeat the same sequence and get the same result.

That made it look repeatable rather than like a one-off crash.

Looking at KWin

I checked the compositor logs after reproducing the problem.

The relevant crash was occurring inside KWin rather than in Edge itself.

The display was also being re-detected after the crash, which explained the misleading "new display detected" behavior.

That narrowed the problem down considerably.

The next question was what KWin was doing differently when a window entered fullscreen.

Direct Scanout

Wayland compositors can sometimes bypass parts of the normal compositing process when a fullscreen surface can be displayed directly on a monitor.

This is called direct scanout.

Normally, the compositor combines the visible surfaces into a final frame and sends that frame to the display.

With direct scanout, a fullscreen surface can potentially be presented directly instead of going through the normal compositing path.

This reduces compositor work and can lower latency.

The problem is that this path interacts with the display and GPU stack differently from normal compositing.

In my case, fullscreening Edge on the secondary monitor appeared to trigger a failure in that path.

The Important Clue

The important clue was the sequence of symptoms:

Fullscreen Edge → black screen → KWin crash → display re-detected

The monitor wasn't physically disappearing.

KWin was failing during the transition into the fullscreen presentation path.

That pointed to the direct-scanout path as the likely failure point.

Testing the Theory

The simplest test was to disable direct scanout and reproduce the same fullscreen action.

I disabled it using the relevant KWin environment/configuration workaround and then tested Edge again.

After that, fullscreening Edge on the secondary monitor stopped crashing the session.

I repeated the same fullscreen action, and the session stayed up.

That gave me a practical way to isolate the problem.

The Workaround

The workaround was to disable direct scanout.

This isn't a universal fix for KWin crashes. It was useful here because disabling the feature removed the specific presentation path that was triggering the crash.

The trade-off is that the compositor has to do more work.

That can slightly increase compositor and GPU usage.

For my setup, that was a reasonable trade-off compared with having KWin crash whenever Edge entered fullscreen on the second monitor.

What I Learned

The confusing part of this bug was that the visible symptom looked like a monitor problem.

The display went black and KDE reported that a display had been connected again.

But the actual failure was KWin.

The useful debugging lesson was to follow the complete sequence instead of assuming the first visible symptom was the cause.

In this case:

Fullscreen
    ↓
Direct-scanout transition
    ↓
KWin crash
    ↓
Display re-detection

Once the crash itself was identified, the display behavior made much more sense.

If You Hit Something Similar

If KWin crashes specifically when fullscreening an application on Wayland, check:

KWin crash logs
GPU driver information
Whether the problem is limited to one display
Whether it happens only with fullscreen windows
Whether disabling direct scanout changes the behavior
Whether the issue is reproducible with another application

Also check whether the problem changes when using different GPU/display combinations on hybrid graphics systems.

Don't immediately blame the monitor just because the screen goes black.

Check the compositor before blaming the monitor.

Environment

My relevant environment at the time of testing included:

OS: CachyOS
Desktop: KDE Plasma 6
Session: Wayland
GPU: Hybrid AMD/NVIDIA
Browser: Microsoft Edge
Primary display: 1920×1080 @ ~180 Hz
Secondary display: 1920×1080 @ ~60 Hz

Your exact behavior may differ depending on your GPU, driver version, display configuration, and KWin version.

Final Takeaway

The crash initially looked like a monitor disconnect.

It wasn't.

The reproducible trigger was fullscreening Edge on the secondary display, and disabling direct scanout prevented the KWin crash on my system.

For now, I'm keeping the environment/configuration change as a workaround rather than treating it as a permanent fix.

The proper long-term solution would be for the underlying KWin/graphics-stack issue to be identified and fixed upstream.

Sources

KDE / KWin documentation
Relevant KWin crash logs from the affected system
Linux graphics/display documentation
Relevant upstream issue and driver information

Samsung A15 Has No App Lock - Samsung Calls It 'Secure' Anyway

Musa Nayyer — Mon, 29 Jun 2026 11:05:55 +0000

Samsung A15 Has No App Lock - Samsung Calls It 'Secure' Anyway

I wanted to lock one app with a fingerprint. No Secure Folder, no third-party garbage, just a native PIN or fingerprint lock on a single app. Straightforward. Except it isn't - because Samsung has no native App Lock in One UI, and there's no clean way to get it.

The Problem

The Samsung Galaxy A15 is running One UI 8, Android 16. Biometric hardware is there. The "secure" branding is all over the box. But when I went to Settings → Biometrics and Security, App Lock was nowhere.

I searched "App Lock" in the Settings search bar. Nothing. I checked under Lock Screen. Nothing. The only lock-related result I found was "Hide content while locked" - which just hides notification previews on the lock screen. Completely different feature.

What I Tried

Settings → Biometrics and Security → no App Lock entry
Settings search bar → "App Lock" → zero results
Settings → Lock Screen → scrolled everything → not there
Galaxy Store → searched "S Secure" (Samsung's dedicated app locker) → not found
Device: Samsung Galaxy A15, One UI 8.0, Android 16 ## What's Actually Going On

This isn't a budget phone problem. App Lock is missing from Samsung's One UI across the board - A series, S series, all of them. Users on flagship devices are filing the exact same complaint on Samsung Community forums. Samsung never had a dedicated native App Lock built into One UI itself; it was always either Secure Folder or the now-discontinued S Secure app.

S Secure was Samsung's standalone app locker. It's been pulled from the Galaxy Store entirely. You won't find it.

And One UI 8.5 doesn't fix this for global users either - the App Lock in 8.5 is part of Samsung's Smart Manager, which is exclusive to China. The rest of the world gets nothing new.

Why All the Alternatives Fall Short

Secure Folder - Requires a Samsung account. Creates a separate storage partition. Overkill for locking one app, and it ties you into Samsung's ecosystem just to get basic access control.

F-Droid open source app lockers - No mature, actively maintained option exists. Most are abandoned or launcher-dependent.

Google Play third-party apps - Full of ads, background services, and privacy red flags. And they can be bypassed - anyone can go to Settings → Apps → uninstall the locker with zero authentication, and everything unlocks instantly. That completely defeats the purpose.

What Should Be Different

App Lock is not a complicated feature. Xiaomi, OPPO, OnePlus ship it natively even on their cheapest devices. Samsung had S Secure, pulled it, never replaced it in the OS, and still sells these phones as "secure."

The "secure" in Samsung's branding refers to hardware-level encryption and Knox architecture - not feature completeness. That's a real distinction, but it should be on the box, not discovered after the fact by the person who just bought the phone.

TIL

App Lock being missing from Samsung isn't a Galaxy A15 problem - it's missing from the entire One UI lineup globally. S Secure is gone. The 8.5 fix is China-only. There is no timeline for global users.

Local AI SOC Server on a Laptop - What Actually Broke

Musa Nayyer — Tue, 09 Jun 2026 10:57:12 +0000

I'm a cybersecurity student. No budget, no enterprise hardware, no client environments.

I set it up as a local AI server for SOC automation: log triage, CVE analysis, security bots. The internet made it look straightforward. It wasn't. This is the honest version of that story.

One thing upfront: everything here ran on self-generated test data and my own lab logs. No client data, no sensitive information, nothing real. I'm documenting a learning build, not a deployment guide. Don't point this at anyone's actual environment until you've properly hardened it beyond what I did here.

The OS Decision - What I Considered and Why It Actually Matters

Most answers online say "just use Ubuntu" with zero justification. Here's the real breakdown.

Ubuntu 24.04 LTS - What I Used

This was the right call for my situation. NVIDIA driver support is the most mature here, nvidia-container-toolkit installs without a fight, and when something breaks at 2am there's a Stack Overflow thread for it.

The downside: blank slate for security work. You're manually installing nmap, gobuster, everything. For a dedicated inference server that's fine, less noise. For a daily driver where you also want to pentest, it gets tedious.

Parrot OS / Kali Linux - Worth Considering

Both are Debian-based and ship with the full offensive toolkit pre-installed. Parrot is lighter and more workable alongside inference workloads. Kali is the standard for dedicated pentest infrastructure.

The appeal: your AI stack and your security toolchain live in the same environment. No dependency wrangling between two systems. The catch: don't run heavy inference and an active nmap scan simultaneously without capping container resources. They'll fight over RAM and both degrade.

Proxmox VE - Good Idea, Painful on Laptops

Turns the machine into a bare-metal hypervisor. Ubuntu for Ollama, Kali for tooling, LXC containers for bots, all isolated, all snapshotted. Great for client work in theory. GPU passthrough on a laptop is genuinely painful though: IOMMU, VFIO config, WiFi driver issues in guests. Skipped it for that reason.

NixOS - Long-Term Interesting, Steep Curve

Entire server state lives in one declarative file. Reproducible, version-controlled, no config drift. Compelling on paper but CUDA/GPU support requires specific Nix module knowledge. Worth it eventually if you're comfortable with infrastructure-as-code. Not where I started.

Model Stack - What the Internet Says vs. What I Hit

You'll see this configuration recommended everywhere:

Workload	Model	Approx. RAM (inference only)
Code audit / vuln review	`deepseek-coder-v2`	~10 GB (16B)
Log analysis / SOC triage	`deepseek-r1`	6-9 GB (7B-14B)
General reasoning / recon	`llama3.1` or `mistral`	~5 GB (7B)
Automation bots / agents	`qwen2.5-coder`	~5 GB (7B)

What the table doesn't tell you: these numbers are for inference at idle. In a real pipeline: ingestion scripts, scan tools, and a bot running concurrently, add 4-6 GB on top. On older or low-spec hardware, even 7B models stall after a few runs if the settings aren't tuned.

My actual experience: the models needed more manual configuration than any tutorial mentioned. Default settings caused the model to get stuck mid-automation after a few cycles. Context window size, temperature, and output format all needed tuning before anything ran reliably.

Q4_K_M quantization is a solid starting point, best quality-to-size ratio for most workloads. But treat the whole table as a starting baseline, not a guarantee.

The Automation Pipeline

The basic setup I wired together:

Calling the Ollama API is simple enough:

curl http://localhost:11434/api/generate \
  -d '{"model": "llama3.1", "prompt": "Analyze this log entry for anomalies: [LOG]", "stream": false}'

The curl call works fine in isolation. Getting it to behave consistently inside an automated pipeline is the different problem, more on that below.

For visual workflow automation, n8n self-hosted in Docker handles the glue between file watchers, Ollama calls, and notifications well. For CLI piping, Fabric is cleaner: cat auth.log | fabric --pattern analyze_logs just works with less overhead.

One Thing I'd Do Differently

Isolate Ollama in Docker from the start. I didn't, and when an automation script misbehaved it had more filesystem access than it should have. On a personal lab machine that's annoying. On anything with real data it would be a serious problem.

For anyone building something similar, even just for learning:

Default-deny at the container network level
Never expose port 11434 outside localhost
Put Nginx with auth in front if you need remote access

The Part Nobody Talks About - The Actual Hard Part

The bottleneck isn't inference speed. It's not even which model you pick.

It's getting structured, parseable output consistently enough to feed into downstream scripts.

Models are inconsistent by default. Valid JSON for 20 runs, then a plain sentence on run 21, then a half-finished response on run 22. Your pipeline breaks on the edge cases, not the happy path.

Prompt engineering for reliability matters more than model size here. A smaller model with a well-structured prompt will outperform a larger model with a vague one inside an automation pipeline every time.

That's the thing I'd tell myself at the start.

Claude's Visualize Feature Is Broken — Here's a One-Line Workaround

Musa Nayyer — Fri, 05 Jun 2026 06:50:19 +0000

Since mid-March 2026, a significant chunk of Claude users have been hitting this error whenever Claude tries to render an inline diagram, chart, or interactive widget:

Failed to set up MCP app for "visualize".
Check that claudemcpcontent.com is not blocked by your network or browser.

The instinct is to blame your network. I went through the same cycle — switched DNS to Cloudflare 1.1.1.1, tried Google 8.8.8.8, disabled browser extensions, tested across browsers. Nothing worked.

Then I ran a direct DNS lookup:

nslookup claudemcpcontent.com 1.1.1.1

Output:

Server:   1.1.1.1
Address:  1.1.1.1#53

*** Can't find claudemcpcontent.com: No answer

Same result with 8.8.8.8. The domain doesn't resolve — at all, from any resolver. Not a user-side issue.

What's Actually Happening

Claude's visualize feature depends on an external domain — claudemcpcontent.com — to serve the MCP app that renders inline SVG/HTML widgets. When that domain goes down, the feature breaks silently with a misleading error that makes it look like a local network problem.

There's an open GitHub issue tracking this (#34820 on anthropics/claude-code) filed March 16, 2026. It has 50+ affected users, no official fix, and was labeled invalid because it was filed on the wrong repo. Anthropic hasn't responded substantively. The visualize infrastructure had multiple incidents throughout April 2026.

The Workaround

Instead of asking Claude to generate a diagram or chart (which triggers the broken MCP visualizer), ask it to generate a PNG file using Pillow.

Instead of:

"Create a bar chart showing X"

Say:

"Create a bar chart showing X as a PNG file using Pillow"

Claude writes Python, executes it via its bash tool, and drops a downloadable PNG in the outputs directory. No MCP dependency. No claudemcpcontent.com. Completely different rendering pipeline.

Works for bar charts, line graphs, flowcharts, architecture diagrams — anything you'd normally visualize inline.

TIL

Claude's inline visualizer depends on an external domain serving an MCP app. When that domain goes down, the feature fails with an error that looks like a local network problem. Asking for a PNG via Pillow bypasses the dependency entirely.

CachyOS Wouldn't Install and My NVMe Was the Problem (Corrupted GPT + chwd Fix)

Musa Nayyer — Fri, 29 May 2026 11:47:30 +0000

CachyOS Wouldn't Install and My NVMe Was the Problem (Corrupted GPT + chwd Fix)

I was setting up CachyOS on a secondary laptop — i7 11th Gen, NVIDIA mobile GPU, Micron 2210 NVMe. Should've been a clean install. It wasn't. Two specific things broke and both of them looked like my fault until they weren't.

Problem 1: The NVMe with an Identity Crisis

The CachyOS installer (Calamares) failed to create a partition table on the Micron 2210 NVMe. No useful error, just a failure. I dropped into the terminal and ran gdisk:

sudo gdisk /dev/nvme0n1

Three warnings. Then this:

MBR: not present
BSD: not present
APM: not present
GPT: damaged
Found invalid MBR and corrupt GPT.

The drive had a corrupted GPT and ghost MBR headers from a previous install. The Calamares installer couldn't write a clean partition table because it was fighting old metadata it couldn't fully read or overwrite.

The fix is a full zap from inside gdisk:

sudo gdisk /dev/nvme0n1
# at the prompt:
x        # enter expert mode
z        # zap GPT data — confirm with y
         # then zap MBR — confirm with y

Drive came out completely clean. Re-ran the installer, partition table created without issue.

If gdisk can't get there, hit it with wipefs first:

sudo wipefs -a /dev/nvme0n1

Intel VMD note: If you're on an 11th Gen Intel laptop, check your BIOS for Intel VMD (Volume Management Device). If it's enabled, Linux can see the NVMe drive but can't write to it properly. Disable VMD or switch from RAID to AHCI/NVMe mode before trying any of the above.

Problem 2: chwd Killed the Install Mid-Way

After getting past the NVMe issue, the installer failed again — this time at chwd, the CachyOS hardware detection tool. The online installer couldn't pull the driver profiles, likely a mirror timeout.

The fix: switch to the offline installer.

It installs a default desktop from the USB without pulling anything from the network. Once booted into the system, run hardware detection manually:

sudo chwd -a

That scans your hardware and applies the right driver profiles — in my case, the Intel + NVIDIA hybrid (Optimus) setup for the laptop.

TIL

Old partition metadata is silent until it isn't. Before installing anything on a drive that's been used before, zap it manually — don't trust the installer to do it cleanly.

muzasio #til #devlog #techexperiment #linux #cachyos #nvme #archlinux

I Tried Building a Complex Security Tool with a 1.5B Local Model — Here's What Broke

Musa Nayyer — Wed, 27 May 2026 20:06:50 +0000

Problem: I had aider running on Lubuntu, three API keys configured, a detailed architecture diagram, and a clear goal — build a modular forensic data analysis pipeline. What I actually got was token walls, a model that replied "Ok." to everything, and a half-made project directory with nothing inside it.

The Setup

Installed aider via the official shell script on Lubuntu. Connected three models:

OpenAI — failed outright, key didn't authenticate
Grok — worked partially, got some directory scaffolding done before tokens ran out mid-session
Ollama local (Qwen 2.5 Coder 1.5B) — connected fine after setting OLLAMA_API_BASE=http://localhost:11434, but the model kept responding with "Ok." and two tokens flat The architecture I was trying to build had seven layers: data acquisition, integrity hashing, normalization, schema mapping, anomaly detection, explainability, and 3D visualization with Three.js. Ambitious. Too much for a 1.5B model to hold in its head at once.

What I Tried

First I threw the whole diagram at aider and asked it to scaffold everything. Grok started making directories. Tokens ended. Switched to local Ollama. Local model saw the repo map, said "Ok." — twice. No output, no errors, no explanation.

I tried prompting it to list the project structure. Still "Ok." Tried asking it to read what happened in the folder. "Ok." The model wasn't broken — it was overwhelmed. A 1.5B model with a full repo map in context has almost no room left to actually generate code.

Then I realized the real problem: I was treating a small local model like a senior engineer. It's not. It's a fast, cheap code-completer that needs a tight scope and a single task.

What Actually Worked

Three things changed the outcome:

1. One module at a time. Instead of "build the pipeline," I asked for one function in one file. The model went from "Ok." to producing real code.

2. /read instead of /add. Using /read for files the model doesn't need to edit cuts token usage significantly. The model gets context without burning its window on write permissions.

3. Git as memory across models. When Grok's tokens ran out mid-session, I committed whatever it had produced. When I switched to Ollama, I opened with: "The previous model created the acquisition and integrity folders. Look at the current files and continue with the normalization script." The local model picked up cleanly — because git was the real memory, not the chat history.

Result

Got a working acquisition/ module and a schema/event_schema.json with the Canonical Event Schema defined. The hashing layer and normalization parser came from the local model once I stopped giving it too much context at once. The Three.js visualization is still pending — that's a job for Gemini's free tier, which handles frontend/creative code better than a 1.5B coder model.

The pipeline isn't done. But the architecture is solid and every module has a defined input/output contract, which means any model can continue any piece without needing the full history.

TIL

A 1.5B local model isn't bad at coding — it's bad at holding a complex project in context. Split the work into single-function tasks, use git commits as handoff points between models, and let the repo map do the heavy lifting instead of bloating the chat history.

muzasio #til #devlog #techexperiment #aider #ollama #localai #cybersecurity #linux

Signal QR Stuck on Spinner — University Firewall Was the Culprit

Musa Nayyer — Sun, 24 May 2026 06:43:16 +0000

Problem: I tried linking my iPhone as a secondary Signal device. The QR code just spun forever — a loading spinner inside a white box. No error. Just nothing.

My setup: Primary device — Redmi 13C (PTA), Signal registered and working. Secondary device — iPhone (non-PTA). University Wi-Fi. I wasn't doing a full registration or transfer. Just: Settings → Linked Devices → Link New Device on iPhone. Dead silence from Signal.

What I Tried

First assumption: it's the non-PTA iPhone. Maybe Signal's blocking it? Nope — PTA status is a cellular registration thing. It has zero effect on Wi-Fi app behavior.

Second assumption: maybe I need to select "transfer from Android"? Nope — I didn't want a transfer. Just a secondary link. The flow is: iPhone shows QR → Redmi scans it.

I got the flow backwards at first too. Thought Redmi generates QR, iPhone scans. Wrong. iPhone (secondary) generates the QR. Redmi (primary) scans it.

The QR never loaded on iPhone. That's when it clicked — it's not the phone, it's the network.

What Actually Happened

Signal's QR code generation isn't local. The iPhone hits Signal's provisioning API (api.signal.org, storage.signal.org) to create a time-sensitive token before displaying the code. My university network was blocking those endpoints.

Why did Redmi register fine earlier? Probably a different time, different access point, or Android and iOS clients have different TLS fingerprints — and the firewall's application-layer inspection treats them differently. University-grade firewalls (Fortinet, Palo Alto) do this.

The Fix

Proton VPN on both devices, same server location.

Installed Proton VPN (free tier) on both iPhone and Redmi
Connected both to the same server (Netherlands)
On iPhone → Signal → Linked Devices → Link New Device
QR code appeared instantly
Redmi scanned it — linked successfully

6. Redmi got logged out immediately after. That's not a bug — Signal logs out existing sessions when a new device links, by design. Re-registered with the phone number and everything was fine. Message history is local anyway; it doesn't sync across linked devices.

Key Insights

The QR code requires a live API call. If Signal's servers are unreachable, the spinner loops forever with no error message. Signal could honestly show a better error here.
iOS and Android Signal clients behave differently at the network level. A firewall can block one and pass the other.
University networks block more than you think. VoIP, messaging APIs, certain CDN routes — it's not just torrents.
Free VPN is enough for this. Proton VPN free tier worked fine. No speed requirements for a one-time provisioning handshake.

- Both devices need to be on the same network exit. The provisioning token is bound to the originating network context. If iPhone generated it over VPN and Redmi scanned from plain university Wi-Fi, it failed with "QR code not valid."

TIL

Signal's device linking QR is a remote token, not a local code — and if your network blocks Signal's API endpoints, you'll get an endless spinner with zero explanation.

Firefox Profiles Frozen and Corrupted on CachyOS — What Broke and How psd Was the Culprit

Musa Nayyer — Fri, 22 May 2026 12:35:15 +0000

The Problem

Opened Firefox one morning and the profile picker showed up. Clicked my main profile — nothing happened. Hover worked, tooltips appeared, but clicks registered nowhere. Profile 1 was already dead the day before. Only the third profile (sss) responded. Main profile had six accounts in it.

What I Tried

Keyboard navigation — nothing. Tab and Enter didn't work either.

Checked the Firefox profile directory and found this:

lrwxrwxrwx  lbjm2hpz.Profile 2 -> /run/user/1000/psd/user-firefox-lbjm2hpz.Profile 2
lrwxrwxrwx  xcpk3xfu.default   -> /run/user/1000/psd/user-firefox-xcpk3xfu.default

Symlinks. Not real directories. psd (profile-sync-daemon) moves Firefox profiles to RAM and replaces them with symlinks. The RAM targets were either empty or broken.

Ran psd preview — confirmed psd was managing both profiles. xcpk3xfu.default showed profile size 0. That profile was already gone.

Tried psd resync — ran without errors but didn't fix the picker clicks.

Tried launching directly from terminal:

firefox --profile "/home/user/.config/mozilla/firefox/lbjm2hpz.Profile 2"
firefox -P "default-release" --no-remote
MOZ_ENABLE_WAYLAND=0 firefox --profile "/home/user/.config/mozilla/firefox/lbjm2hpz.Profile 2"

All three kept opening the sss profile instead. The --no-remote attempts threw repeated channel errors because Firefox was already running.

Checked about:profiles — confirmed the current window was actually running default-release (the main profile), but it was completely empty. No accounts, no history, nothing. The 49M of data was somewhere but Firefox wasn't seeing it.

Stopped psd, deleted the broken profile directory, tried restoring from the -backup folder — backup had disappeared when psd stopped (psd overwrites it on shutdown with whatever is in RAM). Only a crashrecovery folder from earlier that morning survived with 49M of actual data.

Restored from crashrecovery, started psd again — psd immediately created a new symlink pointing to RAM and the profile went missing again. psd was overwriting the restore on every start.

The GUI click issue turned out to be a separate Wayland input problem with the Firefox profile picker — unrelated to psd but compounding the mess.

Root Cause

psd syncs browser profiles to RAM for speed. On unclean shutdowns or crashes, the sync back to disk fails. The -backup folder gets overwritten on the next psd start with whatever empty state is in RAM. Over time this had been happening repeatedly — the profile directory had 64 crash recovery folders going back months, all showing the same pattern.

xcpk3xfu.default was already fully gone. lbjm2hpz.Profile 2 survived only because a crashrecovery snapshot existed from earlier that same day.

The Fix

Disabled Firefox in psd by adding this to ~/.config/psd/psd.conf:

BROWSERS=(google-chrome)

Restarted psd. Firefox now reads directly from disk. No more symlinks, no more RAM sync, no more silent corruption on shutdown.

Also ran psd clean to delete the accumulated crash recovery folders and reclaim disk space.

TIL

psd is a silent data risk on systems that crash or suspend frequently — it will eat your browser profiles and leave behind only empty backup folders.

DEV Community: Musa Nayyer

Store-and-Forward Explained: Inside a Router, From the Book to Linux

Part 1: Store: Nothing Leaves Until the Last Bit Arrives

The question

What I found

Where the "store" happens on Linux

Key idea

Part 2: Why Wait? The Error Check Is at the End

The question

What I found

Checking it on Linux

Key idea

Part 3: Forward: What Linux Does With the Frame

The question

What I found

Checking it on Linux

Key idea

Part 4: The Four Small Edits at Every Hop

The question

What I found

Exceptions worth knowing

TTL and traceroute

Key idea

Part 5: The Cost: N × L/R

The question

What I found

Where this fits among the four delays

Key idea

Part 6: Why Your Data Is Cut Into Small Packets

The question

What I found

Key idea

Part 7: Not Every Box Waits

The question

What I found

Key idea

Summary

References

Learning TCP/IP From the Linux Side: Spec, Code, and Wire

Part 1: From Application Data to the Network

The question

What I found

Why it matters

Part 2: Layer 2 vs Layer 3, Seen From Linux

The question

What I found

Part 3: One TCP Header, Three Views

The question

View 1: The spec

View 2: The code

View 3: The wire

The checksum gotcha

Part 4: How TCP Knows an RST Is Legitimate

The question

Sequence numbers as a defense

RFC 5961 tightened the check

Checking it on Linux

What to look for in Wireshark

Blind vs on-path attackers

Key idea

What Changed in How I Learn

References

Containers Are Isolated, But They Still Share the Kernel

Containers Are Not Small Virtual Machines

What Actually Isolates a Container?

Namespaces: What Can the Process See?

cgroups: How Much Can It Use?

Capabilities: What Privileged Operations Are Allowed?

User Namespaces: Is Container Root Also Host Root?

seccomp: Which System Calls Can the Container Make?

AppArmor and SELinux

Case Study 1: Copy Fail — CVE-2026-31431

The Important Concept: Reachability

Case Study 2: CVE-2026-80521 and AF_UNIX

A necessary distinction

What Does "Container Escape" Actually Mean?

A Small Hands-On Demonstration

Check Docker's Security Configuration

Compare Container and Host Processes

See What Happens With --privileged

See What Happens With `--privileged`