This write-up is an informal presentation of how I found an encryption vulnerability in a line of network equipment, developed an exploit to demonstrate proof of concept, reported the vulnerability to the company, tested their patch, and worked with them to issue an advisory.

For a more concise analysis, please refer to the formal report available on GitHub just below.

I originally wrote this up back when I was writing the proof of concept. It tells the story of how I ended up finding these vulnerabilities and explains the extent of the effects in the broader context of network security. Despite being built upon older reported vulnerabilities, the encryption vulnerability demonstrated here has not been previously published to my knowledge, nor have any of these vulnerabilities previously been framed in the context of breaching VLAN segmentation.

However, I wanted to keep all the updates to progress on this up here at the top. This steps a bit out of chronological flow, but all the relevant reports and patch updates will be up here at the top as they become available.

Proof of concept code included here and in the repository are for authorized testing purposes only. Encryption keys are redacted.

Disclosure information updates

My formal reports were disclosed directly to TP-Link via private repository which has now been made public.

GitHub - geeklynad/TP-Link-ESCU

Contribute to geeklynad/TP-Link-ESCU development by creating an account on GitHub.

GitHubgeeklynad

TP-Link verified the vulnerability and has released patches for the entire line of products. Follow the link below and search for the model number, or scroll down to the Business > Business Switches > Easy Smart section for a complete list. Both the Configuration Utility and device firmware must be patched in order to resolve the vulnerability.

Download Center | TP-Link

TP Link - Download Center

TP-Link

Reports were also sent to MITRE for CVE reservation, and CVE-2022-44231 has been assigned to this vulnerability.

CVE -CVE-2022-44231

The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities.

CVE-2022-44231

As I explained to TP-Link, my intention of disclosure of this vulnerability is not to enable attacks on existing systems, but rather to inform network and security professionals of the attack vector in order for them to be able to take the necessary steps to mitigate it.

I have included notes on mitigation of the potential attack without patching in my formal report section, Mitigation Suggestions. Although this may prove inconvenient, the login credentials can only be captured during an active session with the device so isolating the device during configuration can be a surefire method to prevent the session from being captured.

However, since the patches are now available, this mitigation method should no longer be required for secure transmission of login credentials while using the Configuration Utility.

A brief note on VLANs

When familiarizing oneself with VLANs, it's common to come across verbiage that indicates that VLANs might not be the most secure way to go. Many of the broad descriptions make allusions to problematic configurations that potentially lead to leakage between network segments.

This initially struck me as an issue of either user error in setting up inter-VLAN routing and firewalls, or possibly legacy hardware issues that have long since been sorted and resolved. I wasn't expecting to come across this issue in the form of current-patch, up-to-date firmware blatantly mishandling VLAN segmentation so soon into my VLAN misadventures.

For a basic run-down, VLANs can be set up in such a way as to make all of the network infrastructure accessible only through a management segment. This improves the security profile by limiting access in addition to control lists, accounts, and passwords. If a user isn't connected through the management segment, they can't log in to management interfaces. The access between VLANs is ultimately in control of the routers designated to perform inter-VLAN routing. Firewall rules can be as broad or as granular as needed depending on the requirements. But the main idea is to have limited, controlled points through which inter-VLAN traffic can flow. The rest of the VLAN traffic gets directed to those points.

There shouldn't be any traffic that exchanges between VLANs without having to run the gauntlet of the firewall rules and routes in those designated control points.

I previously put together a deep dive explanation of VLANs, topology, and the TCP/IP and OSI models using visualizations aimed at making the topics accessible to a wide audience. If you'd like to know more about VLANs and what they can be used for, it might be worth a read.

The strangest explanation of VLANs you’ve never heard

Mental models rarely fit neatly into little boxes, yet we try to visualize them using overly simplistic means. For once, let’s get a little nutty.

geekly.devNad

What's in the box?

When I first installed and configured my shiny new TL-SG105E v5, I was briefly elated by the simplicity of the 802.1Q configuration. Tell it which access ports are members of which VLAN, tell it where to untag traffic going out to end points, tag traffic for the trunk line, and which PVIDs to use. Seemed to work like a charm!

But one thing was bothering me. It was fetching itself an IP address from the DHCP server (my pfSense from which the VLANs stem) that was within one of the VLANs. Not the native VLAN, and not the management VLAN. And it wasn't consistent upon reboots. It seemed to pick a VLAN at random, grab an address in that VLAN, and sit quite happily in the wrong place for the rest of its power-on cycle.

In other words, it was not fetching its own address from the native VLAN, the base network. And there was no way to limit which VLAN it would choose to run its DHCP client on. Because of its random assignment nature, it would be troublesome to secure the management interface to be accessed only through the management VLAN.

Why not have it self-assign a static address?

If this bouncing around were the only problem, that might actually work to resolve the issue. Instead, it just gets worse.

It took a while for it to sink in enough for me to realize what was going on. I thought that maybe I was making mistakes, failing to take things into account.

I set a static IP for it in the management VLAN, but I was able to access the management interface from non-management VLANs. From VLANs that were not the "wrong seat" that the little switch decided to rest in. I had no business being able to access something that resides in that VLAN from this one, and yet here I am, logging into this switch to try to figure out why it chooses to do what it does. I thought that maybe I had DHCP leases that were still active, or that my MAC was on an ARP table somewhere in the pipeline for a VLAN that I was previously logged into. These were not the case. The rest of the network was handling VLANs as intended. The bleed-through wasn't coming from somewhere else.

In short: If this switch is plugged into a trunk line that contains the VLAN you're on, it'll respond.

In this instance, the switch fetched DHCP for VLAN99, the management VLAN. That segment is isolated from the rest of the network via interVLAN routing rules and firewall rules. However, because a trunk line extends to the network, the switch is able to disregard the rules present on other devices. It does what it wants. And what it wants is to ignore the way VLAN filtering works.

None of this bodes well.

At this point, it was time for some forum scrubbing. I pretty much immediately came across this write-up, Not So Smart: TP-Link TL-SG105E V3.0 5-Port Gigabit Easy Smart Switch by DrGough's TechZone.

And yes, it gets worse.

Not only does this switch advertise and accept connections from any VLAN with no option whatsoever to limit access, it transmits login credentials via HTTP in plaintext.

DrGough's TechZone found that it was possible to functionally brick log-ins by causing a buffer overflow, using curl to set credentials beyond the input validation limits set by the interface. This enables some degree of security. Set up the switch how you want it, brick the login, and if you ever need to change anything back, cycle the power to restore management login functionality. However, seeing as the "fix" becomes negated by a power outage, this shouldn't be categorized as a long term solution unless you really enjoy sending curls to your switch every time your power goes out.

That write-up also cited an older write-up, How I can gain control of your TP-LINK home switch by PenTestPartners.

And yes, it gets worse.

In it, they specifically examined the management application offered as a sleeker alternative to the HTTP management interface, the Easy Smart Configuration Utility.

PenTestPartners found that:

• The utility communicated with the switch (and vice versa) via broadcast (255.255.255.255) UDP.
• The utility was in java, and readily decompiled to source code.
• The encryption used was RC4 with a static key.
• The static key was within the decompiled source code.

Given these factors, it then becomes possible to intercept switch management traffic and decrypt it from elsewhere on the network.

This is looking more and more like a really nice pivot point to get through VLAN segmentation.

Let's say for the sake of fun you're on a network in a given VLAN segment trying to access a device on another VLAN segment. Switches and routers on the network adhere to the VLAN filters. Firewall rules strictly limit crosstalk. You can't see it on any network scans. You know it's there though. Luckily for you, it's behind an Easy Smart Switch. You gain access to the switch's management interface (because it's friends with everybody and still happily sitting in the wrong place) and reconfigure the target's access port to the VLAN of your choosing. You're now free to poke around at whatever open ports are listening on that device.

Such an attack wouldn't be limited to having both the attacker and the target behind the same switch. If the attacker is behind the switch but the target is elsewhere on the network, the attacker would be able to reconfigure the access ports of the switch to open up any VLAN being fed via trunk line to the switch.

If the switch's trunk includes the target's VLAN, the attacker can gain access to the target's VLAN, completely bypassing interVLAN routing and firewall rules.

Neither of the two write-ups really examined these possible attacks in the context of VLANs. However, since "VLAN capable" and "802.1Q compatible" are main selling points of this device, and that's what I wanted to use it for, that's the microscope I'll be putting this device under.

How much of this is still a problem?

The two write-ups were sent in to TP-Link years ago. One for v1, one for v3. There have been patches made to both the switch firmware and to the management utility.

The short answer is: All of it.

They did try to mitigate the attack on the utility encryption. These attempts, however, were insufficient to solve the problem. They made it more difficult to achieve the same results, but it is absolutely possible to achieve significant results.

The HTTP unencrypted login problem still exists.

That rules out using the web browser as the management interface. What about the Easy Smart Configuration Utility?

• It still utilizes broadcast to communicate all packets.
• It's still a java package that's readily decompiled.
• It still utilizes static key RC4, albeit in a different form now.

The login credentials remain obtainable, permitting an attacker to gain control of the VLAN configuration to bypass segmentation. If this device is offered a VLAN trunk line, or configured to be the root of VLANs, it is possible to break out of VLAN segmentation.

How did TP-Link respond to previous reports?

Let's take a look back at TP-Link's response to PenTestPartner's report.

I had a discussion with TP-LINK’s support who were really responsive, and I’ll quote them directly to ensure that I don’t misphrase them:

1. Traffic between utility and switch is sent by broadcast

It is a common way for Utility to communicate with devices with broadcast in our industry, other productors like Netgear does it this way too.

Broadcast will have some shortcomings as you said and we will think about it too, but the premise is LAN is not safe.

In most scenes LAN is a relative safe environment. We will have NAT router and firewall in front of our LAN network, most attacks will be blocked. Firewall and secure software can protect our LAN’s safety. But when LAN is not safe, even we don’t use broadcast, other method like faked ARP can get traffics between utility and switch.

2. Decode of Utility exe and static encryption.

Our Easy Smart Switch is a product for home and small office, so chip is not powerful enough to ensure a very high security.

As you know, Utility is written in Java and it means decompilation is avoidless, anyone can do it if they know how. It is the cost of Java’s universality and we can’t change it. Our R&D will think about add more covers to our codes to make our switch more safe in next Utility.

Before talking about the mitigation measures they used, going over their response will help illustrate the reasoning behind the measures taken.

In most scenes LAN is a relative safe environment.

Because the report wasn't framed in terms of VLANs, VLANs weren't considered here. But even given that, I have to voice at least a little contention with the idea of LANs being considered a safe environment. In a wild logically fallacious leap, they cite ARP poisoning in some sort of equivocation to broadcast, ignoring the possibility of mitigating measures taken against such attacks.

But let's give them the benefit of the doubt that they consider LANs "safe." How do they categorize VLANs? Because VLANs are widely used for segmentation of networks for security purposes. Most home users who put together a network of VLANs do so to separate network traffic based off of security profiles. IoT devices go on a separate segment than servers, which in turn on are on a separate network from daily driver devices, and so on. They are separate for a reason. They need to be able to remain separate.

Having a device that responds in complete disregard to VLAN protocols is how that separation gets broken.

Our Easy Smart Switch is a product for home and small office, so chip is not powerful enough to ensure a very high security.

This may very well be a limiting factor of the device. I don't know what the chip is capable of performing and what it isn't. It can perform RC4. It seems to me that if it's capable of performing RC4, it should be capable of establishing a key exchange to base randomized keys for the RC4. But that's beyond the scope of my familiarity.

I will say that if the device is indeed incapable of performing anything other than RC4 with a static key (and even given that "LANs are safe"), it should not be used for VLANs. It should only be used for "safe" LANs.

As you know, Utility is written in Java and it means decompilation is avoidless, anyone can do it if they know how.

Secure open source software exists. How? For a first clue, you'd be hard pressed to find any open source software that utilizes static keys for RC4. Key exchanges are used in protocols such as TLS to establish encryption keys to be used by either end of the connection. This can eliminate the need for unsecure local storage of key values, as new keys are made and exchanged on the fly.

Let's take a quick look through RFC-5246.

The TLS Record Protocol is used for encapsulation of various higher- level protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security that has three basic properties:

- The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers.

- The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection.

- The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication.

Key exchanges are a proven, very commonly used method of securely handling the overhead of the bulk encryption. Heavy duty, processor-intensive encryption isn't a necessity. RC4 can be argued as being problematic and many vendors are moving away from its use. But RC4 isn't the weakest link in this chain. The static key is. Key exchanges are what enable the use of ephemeral keys. Once the session is finished, the keys are retired. When a new session is initiated, new keys are created and exchanged. This is makes for a much more robust encryption.

Many devices are capable of TLS including a variety of IoT devices with limited processing capability. And TLS is one of a variety of tunneling protocols in widespread use. The fact that Java is readily decompiled should not be a limiting factor of utilizing any of a number of methods of secure transfer of data (including login credentials).

It is a common way for Utility to communicate with devices with broadcast in our industry, other productors like Netgear does it this way too.

I want to conclude the dissection with this one because I feel like it nicely encompasses the problematic paradigm. Don't do things wrong just because others do them wrong. There are others that do things right. That's worth the effort.

What did previous patches fix?

They used some code obfuscation (one that happened to use William Shakespeare quotes as a dictionary - thank you to Constable for finding this gem), switched out the plaintext key in favor of a byte array, and scrambled it using TEA, the Tiny Encryption Algorithm.

This example of TEA is written in C by its creators David Wheeler and Roger Needham. This is the very same algorithm used by the Easy Smart Configuration Utility to internally encrypt the key.

#include <stdint.h>

void encrypt (uint32_t v[2], const uint32_t k[4]) {
    uint32_t v0=v[0], v1=v[1], sum=0, i;           /* set up */
    uint32_t delta=0x9E3779B9;                     /* a key schedule constant */
    uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];   /* cache key */
    for (i=0; i<32; i++) {                         /* basic cycle start */
        sum += delta;
        v0 += ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
        v1 += ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
    }                                              /* end cycle */
    v[0]=v0; v[1]=v1;
}

void decrypt (uint32_t v[2], const uint32_t k[4]) {
    uint32_t v0=v[0], v1=v[1], sum=0xC6EF3720, i;  /* set up; sum is (delta << 5) & 0xFFFFFFFF */
    uint32_t delta=0x9E3779B9;                     /* a key schedule constant */
    uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];   /* cache key */
    for (i=0; i<32; i++) {                         /* basic cycle start */
        v1 -= ((v0<<4) + k2) ^ (v0 + sum) ^ ((v0>>5) + k3);
        v0 -= ((v1<<4) + k0) ^ (v1 + sum) ^ ((v1>>5) + k1);
        sum -= delta;
    }                                              /* end cycle */
    v[0]=v0; v[1]=v1;
}

The plaintext string of 256 alphanumeric values is converted from UTF-8 to integers, and run through this encryption. From there, the integers are then split out into signed bytes ("signed bytes" meaning that one bit is used to signify whether the values are positive or negative; signed bytes range in value from -128 to +127) and statically stored within the code in a byte array.

When a packet needs to be sent or received, the byte array containing the encrypted key is sent back through the gauntlet of stacking signed bytes into integers, then piped into the other end of the Tiny Encryption Algorithm. From there, it's sent back to be turned into a string of 256 alphanumeric values. Then it's piped through the KSA phase of RC4, where it reaches its final form to be used in the PRGA phase where it's combined with the datastream to be either encrypted or decrypted. (In the case of RC4, encryption and decryption is the same operation since it uses bitwise AND between the key and the plaintext/ciphertext.)

The key, although obscured, is still static.

It doesn't change between uses. It doesn't change between clients. This key is consistently used across all hardware to which the Easy Smart Configuration Utility connects, as well as all copies of the utility.

Cracking the fix

I've never programmed Java before. I've barely even read any Java before. I'm not saying this out of pride for inexperience. I'm saying this to illustrate a point.

Obfuscation is not a substitute for protocols.

Did it slow me down? Absolutely. It certainly didn't stop me. If anything, it only served to egg me on with the blooming realization that their resolution to a serious encryption flaw was to basically throw a tattered old (deprecated) rug over a rotting old foot bridge spanning a chasm of despair.

In Java

Because of the bitwise operations used in TEA, it was most feasible for me to do that by patching together the decompiled code, and making an endpoint for the key string itself to print out to console. Once I had the key, I was able to verify that the packets could be decrypted with RC4.

It's worth noting that decompiling with JD-gui gave me code that didn't perform the TEA decryption properly. I eventually tried using Procyon to decompile and got much better results. I'm still scratching my head over why. But for anyone attempting to reproduce, I'd recommend using Procyon for decompiling.

I was able to get the decryption working  for both TEA and RC4 in Java by including the a few dependencies rebuilt from the decompiled source, transfer.TLV, transfer.of and transfer.This. The key has been redacted. Example raw hex Wireshark packet capture is included.

package javadecrypt;

import java.util.Arrays;
import java.util.HexFormat;

public class main {

    // int array to store post-KSA key
    private static int[] mS = new int[256];
    
    // checks if TEA has already been performed
    private static boolean lC;

    public static void main(String[] args) {
        if (lC) {
            return;
        }

        // Send TEA-encrypted key to be decrypted
        final String h = new of().h(new byte[] {REDACTED});
        
        // KSA phase
        final byte[] array = new byte[256];
        int n = 0;
        for (int i = 0; i < 256; ++i) {
            array[mS[i] = i] = (byte)h.charAt(i % h.length());
        }
        for (int j = 0; j < 256; ++j) {
            n = (n + mS[j] + array[j]) % 256;
            final int n2 = mS[j];
            mS[j] = mS[n];
            mS[n] = n2;
        }
        lC = true;

        // Print key post-TEA
        System.out.println("Pre-KSA key plaintext: " + h);
        // Pre-KSA in bytes can be enabled in Key.of.h()
        // Print key post-KSA
        System.out.println("Post-KSA Key in bytes: " + Arrays.toString(mS));


        // Example packet captured from wireshark
        HexFormat hexFormat = HexFormat.of();
        byte[] arrayOfByte = hexFormat.parseHex("5d777eefcbb14f45bfc42eb9cd4d7e51422ba2f5d791aeed508f31d5c202909a591381c0464e465f27d942b5a44c2c4a3a03355a0b08fa1e541489f773e1");

        // Print UTF-8 and byte array of encrypted packet
        System.out.println("Encrypted: " + new String(arrayOfByte));
        for (int length = arrayOfByte.length, i = 0; i < length; ++i) {
            System.out.print(arrayOfByte[i] + " ");
        }
        System.out.println("\n");

        // PRGA phase
        This.Code(arrayOfByte, arrayOfByte.length);

        // TLV.g to build string with de-signed byte values
        System.out.println("Decrypted: " + TLV.g(arrayOfByte));

        // Print de-signed byte values
        for (int length = arrayOfByte.length, i = 0; i < length; ++i) {
            System.out.print((arrayOfByte[i] & 0xFF) + " ");
        }
        System.out.println("\n");
    }
}

In Python

From there, I was able to recreate these operations in Python. Some juggling was required to account for the fact that bitwise operations give different results for different data types.

The original Java code uses big endian signed bytes and unsigned integers, switching back and forth between the two during different part of the operations. The bitwise operations in TEA were difficult to reproduce in Python, but ultimately possible using ctypes conversions for specific steps.

Many of the functions in the "tooling" section are recreations of the included dependencies in the Java example to handle things like packing 8 bytes into 2 ints to pass into TEA, and converting between ints and UTF-8.

This can readily be expanded upon to be used in the context of a packet sniffer to decrypt a datastream as it is received.

#!/usr/bin/env python3
# python 3.10.7
# --------------------------------------------------------------------------------------
# Easy Smart Configuration Utility packet decryption
# nad@geekly.dev
#
# Requires key obtained through decompiling the utility
#
# Expected data type for packet capture is string of hexadecimal string
#   Example included in raw.txt file
#   Contains login credentials of user:admin with password:EncryptFail
#   
#
# Raw hex string can be obtained through wireshark using "Follow UDP stream",
#   setting the output type to "Raw", and pasting into a text file.
#   Each line of raw.txt to contain one packet to be decrypted independently
# 
# Proof of concept performed on TL-SG105E v5, Build 20220414 Rel.50349
#
# Affected hardware includes the following:
# * TL-SG1428PE(UN) V1/V1.2/V1.26/V2/V2.2
# * TL-SG1218MPE(UN) V1/V2/V3.2/V3.26/V4/V4.2
# * TL-SG1210MPE V2/V3
# * TL-SG1024DE(UN) V1/V2/V3/V4/V4.2/V4.26
# * TL-SG1016PE(UN) V1/V2/V3.2/V3.26/V4/V5
# * TL-SG1016DE(UN) V1/V2/V3/V4/V4.2
# * TL-SG116E(UN) V1/V1.2/V2/V2.6
# * TL-SG105E(UN) V1/V2/V3/V4/V5
# * TL-SG108E(UN) V1/V2/V3/V4/V5/V6
# * TL-SG108PE(UN) V1/V2/V3/V4/V5
# * TL-SG105PE(UN) V1/V2
# * TL-RP108GE(UN) V1
# --------------------------------------------------------------------------------------


import ctypes


# --------------------------------------------------------------------------------------
# Tooling for data type conversions
# --------------------------------------------------------------------------------------
#
# Original java used signed byte arrays for datagram stream and ints 0-255 for key
# Since RC4 doesn't use bitwise operations, there's no need to account for endianness
# TEA groups 8 bytes into 2x 32bit ints; ctypes handles bit order


def from_signed(a):
    b = a & 0xFF
    return b


def to_signed(i, bits):
    if i & (1 << (bits - 1)):
        i -= 1 << bits
    return i


def mod_sign(i, m):
    x = from_signed(i) % m
    x = to_signed(x, 8)
    return (x)


def raw_to_bytelist(raw):
    bl = []
    bits = 8
    for i in range(0, len(raw), 2):
        value = int("0x" + raw[i:i+2], 16)
        if value & (1 << (bits - 1)):
            value -= 1 << bits
        bl.append(value)
    return (bl)


def text_to_bytelist(s):
    bl = []
    for char in s:
        bl.append(ord(char))
    return (bl)


def bytelist_to_string(bl):
    str_out = ""
    for x in range(len(bl)):
        str_out += chr(bl[x])
    return (str_out)


# Pack 8 bytes into 2 ints

def chunks(v, i):
    chunk = [0 for a in range(i >> 2)]
    y = 0
    for x in range(0, len(v), 4):
        chunk[y] = (v[x + 3]) | (v[x + 2] << 8) | (v[x + 1] << 16) | (v[x] << 24)
        y += 1
    return (chunk)


# Unpack 2 ints out to 8 bytes

def dechunks(v, i):
    chunk = [0 for a in range(i << 2)]
    y = 0
    for x in range(len(v)):
        chunk[y + 3] = v[x] & 0xFF
        chunk[y + 2] = v[x] >> 8 & 0xFF
        chunk[y + 1] = v[x] >> 16 & 0xFF
        chunk[y] = v[x] >> 24 & 0xFF
        y += 4
    return (chunk)


# --------------------------------------------------------------------------------------
# TEA and RC4 algorithms
# --------------------------------------------------------------------------------------

# TEA key decryption
# y, z, and sum require ctypes.c_int wrapping

def TEA_decrypt(v, k):
    
    # vector ints
    y = ctypes.c_int(v[0])
    z = ctypes.c_int(v[1])
    
    # TEA constants
    sum = ctypes.c_int(0xC6EF3720)
    delta = 0x9E3779B9

    for n in range(32, 0, -1):
        z.value -= (y.value << 4) + k[2] ^ y.value + sum.value ^ (y.value >> 5) + k[3]
        y.value -= (z.value << 4) + k[0] ^ z.value + sum.value ^ (z.value >> 5) + k[1]
        sum.value -= delta

    return [y.value, z.value]


# RC4 key scheduling algorithm
# S initial values set as list 0-255, not as null list with length of 256

def KSA(key):

    keylength = len(key)
    S = [x for x in range(256)]
    j = 0

    for i in range(256):
        j = (j + S[i] + key[i % keylength]) % 256
        S[i], S[j] = S[j], S[i]

    return S


# RC4 psuedo-random generation algorithm
# mod_sign manages the modulo between signed byte values vs 0-255 int values

def PRGA(S, data):

    i = 0
    j = 0
    out = []

    for x in range(len(data)):
        i = mod_sign((i + 1), 256)
        j = mod_sign((j + S[i]), 256)
        S[i], S[j] = S[j], S[i]
        K = S[mod_sign((S[i] + S[j]), 256)]
        out.append(data[x] ^ S[mod_sign((S[i] + S[j]), 256)])

    return (out)


# --------------------------------------------------------------------------------------
# Functions called by main() to decrypt key and packet data
# --------------------------------------------------------------------------------------

# TEA key extraction
# v: Unsign bytes from original signed byte array
# w: Sort into larger chunks, recursive list of 2 ints per chunk
# x: Send each chunk of 2 ints to be decrypted
# y: Separate chunks back out to individual bytes, flatten list recursion
# z: Strip first 8 values (unused offset), Unsign bytes once again and convert to UTF-8

def key_extract(key):

    # TEA key and vector
    k = [2023708229, -158607964, -2120859654, 1167043672]
    v = []

    for i in range(len(key)):
        v.append(from_signed(key[i]))

    w = []
    for i in range(0, len(v), 8):
        w.append(chunks(v[i:i+8], 8))
    if log == True:
        print("Sorted chunks for key extraction: \n", w)

    x = []
    for i in range(len(w)):
        x.append(TEA_decrypt(w[i], k))
    if log == True:
        print("Decrypted chunks: \n", x)

    y = []
    for i in range(len(x)):
        y.append(dechunks(x[i], 2))
    y = [item for sublist in y for item in sublist]
    if log == True:
        print("Decrypted bytes: \n", y)

    z = []
    for i in range(8, len(y)):
        z.append(from_signed(y[i]))
    return (bytelist_to_string(z))


# RC4 decryption
# Set data types
# Run key mutation
# Decrypt
# Encode to UTF-8

def RC4(key, data):

    key_bl = text_to_bytelist(key)
    if log:
        print("Key bytelist: \n", key)

    data_bl = raw_to_bytelist(data)
    if log:
        print("Raw bytelist: \n", data_bl)

    kS = KSA(key_bl)
    if log:
        print("KSA key: \n", kS)

    t = PRGA(kS, data_bl)
    if log:
        print("Output bytelist: \n", t)

    u = []
    for i in range(len(t)):
        u.append(from_signed(t[i]))
    if log:
        print("Un-signed bytelist: \n", u)

    out = bytelist_to_string(u)
    return (out)


# --------------------------------------------------------------------------------------
# Main
# --------------------------------------------------------------------------------------
# Optional: Enable logging for debugging
# Toggle key_ext to true if TEA key extraction is not already stored in key.txt
# Toggle key_print to true if you would like to display the key string

log = False
key_ext = True
key_print = True


# Read files or use built-in
# Key text file expected format is alphanumeric string
#   * Enable logging to display extracted string
#   * Can be pasted into a file to store
#   
# Packet capture expected format is raw hexadecimal
#   * Hex characters only, no escape characters or 0x
#   * One packet per line
#   * Can pull from wireshark using "follow UDP stream", view as "RAW" for hex values

def main():

    # To use built-in key extraction, define the value of key[] here
    # The encrypted byte array can be found in the decompiled source code of the utility
    # If decompiler fills certain values with "Byte.MAX_VALUE",
    #   replace with 127 (max value of signed byte)
    
    if key_ext == True:
        key_bl = [REDACTED]
        key = key_extract(key_bl)
        if key_print == True:
            print("Key string: \n", key)

    # Alternatively, a key stored as a string of alphanumeric values can be imported here
    
    else:
        with open("key.txt", "r") as f:
           lines = f.readlines()
           key = ""
           for line in lines:
              key += line.strip()
           f.close()


    # Load a packet capture file with expected format of RAW hex strings
    
    with open("raw.txt", "r") as g:
        packets = g.readlines()
        g.close()

    # Process each line from raw packet capture as individual packet and print results
    
    for packet in packets:
        raw = packet.strip()
        output = RC4(key, raw)
        print(output)
    
if __name__ == "__main__":
    main()

Again, this decryption works for all these devices. For any of the devices the Easy Smart Configuration Utility communicates with, this applies. The TL-SG105E is not the only piece of hardware that uses this software. It's just the one I'm looking at now.

How would this be used in practice?

Since the utility and switch communicate using 255.255.255.255 broadcast, the packets are easily intercepted by anyone on the same network segment. In order to capture the login credentials, an attacker would have to capture an admin's login. This is made substantially easier with the fact that broadcast is used for all communications with the devices.

This capture can then be decrypted and the login credentials can be extracted. The switch can then be logged into, even from outside of a management VLAN, and reconfigured to either give the attacker access to other VLANs, or expose targets to other VLANs.

I performed my packet captures using Wireshark. However, since management access is not commonly needed on these devices after the initial configuration, logins would be rare. A socket listener can be tailored to wait for any traffic sent on the static port used. Then the attacker could created network traffic anomalies to create the need for an admin to see what's wrong.

That might sound time consuming, or that it would be more effort than worthwhile. In a lot of cases, it very well might be. However, if a network is worth securing then it's worth examining such vulnerabilities. Attacks can and do take place over long periods of time. One of the primary objectives in breaking into a network is to ensure that you'll be able to do so again to be able to spend as much time as required to achieve your objective. This vulnerability opens the possibility of an attacker using any of the Easy Smart Switches to pivot the attack across VLANs.

Reporting and mitigating the vulnerability

Once I had my proofs of concept ready and a thorough report written, I submitted my findings to TP-Link's provided security address. Although they were initially a bit unresponsive at first, later in the process they became much more communicative and expressed gratitude for having worked with them to resolve the issue. I checked in with them periodically through the process to see what the remediation time period looked like and to offer any clarification needed.

About three months after initial disclosure, they provided a patch for me to test. I repeated the process of decompiling and reading through the source to find that they extensively reworked the encryption. While RC4 and TEA were still included for backwards compatibility purposes (a necessary step of being able to patch the firmware of the device), there was new code for entirely different session-based encryption. While I was unable to identify the specific encryption scheme, I believe it's a form of RSA. Don't quote me on that though.

After finding the new encryption and trying to poke at it a bit, I went ahead and flashed the firmware on my device and set about capturing some packets. I was very pleased to find that the encryption changed between sessions. No more static key! And while not all of the transmitted data seemed to use the new encryption, the login credentials were no longer crackable with my proofs of concept.

Other issues such as the use of broadcast transmission and lack of HTTPS were unaddressed yet, but the most crucial vulnerability had been addressed first. I hope they continue along with developing more fixes, as the quality of improvement in this patch is a world of difference from the previous attempt.

I wanted to share a simple visual aid I found useful when it comes to trying to disentangle firewall rules involving many interfaces.

With basic SoHo gateways, firewall rules are fairly easy to visualize. They're entirely designed around blocking unwanted traffic from the WAN interface, and statefully allow traffic from the LAN to go out as needed. There is only one direction to keep in mind, and only a single internal network to worry about.

Things get quite a bit more complicated when operating a more complicated firewall that has influence over multiple internal networks through multiple interfaces. When I first switched over to using a pfSense running quite a few VLANs in my home lab, I had a bit of experimenting to do to figure out which direction the firewall was enforcing for each network interface. Was every rule set on every interface acting bi-direcitonally? Was it only blocking downstream? Were some upstream and some downstream? What is the best way for me to be thinking about this?

I came across a very nice illustration somewhere in my searches. Unfortunately, I wasn't able to dig up the link to be able to share the original diagram. But the visualization stuck with me and has proven to greatly simplify the way I think about my firewall when I need to create new rules.

Let's start with a single interface. The blue is the traffic coming from that network. The red is a unidirectional firewall. Unless specifically told to allow certain traffic types through, it will block all traffic coming from that network (implicit default deny).

If this is a WAN interface, it should be blocking everything by default.

If this is a LAN interface, there should be an allow rule to let the traffic out unless there is a good reason for the network to be isolated.

Let's put a bunch of different interfaces together, now.

The new feature in the middle can be thought of as a "trusted circle".

If traffic from one of the interfaces passes one of its firewall's rules, it is allowed to join the trusted circle. From there, it can be passed along to anywhere else. Because from the direction of the trusted circle, the unidirectional firewalls are not enforcing any rules from that direction.

This shift in perspective answered my internal dialogue about which directions firewalls were facing on which interfaces. It wasn't a matter of upstream to downstream, or from the external to the internal. It was a matter of thinking of each interface as being outside the firewall's trust, and whether or not it would let the traffic in to pass through.

Some other helpful things to keep in mind

That's it for the visualization. That's mainly what I wanted to share. But while you're here, I may as well list out a few other things that I've helpful to keep in mind about firewall rules. [Should be noted that I haven't, by any means, worked with all varieties of firewalls. Thare general rules, but there may be exceptions. When in doubt, RTFM for your specific hardware.]

If nothing else, there is always implicit deny

It's an unwritten (or at least undisplayed) law of firewalls that if no rules apply to the traffic, it will be denied trust.

Rule order is top to bottom

Pretty straightforward. It goes down the list and checks the traffic against each rule until it finds one that applies. If none of the rules apply, it's saved from the spiraling descent into oblivion by the good grace of implicit deny, which banishes it from this plane of existence.

The first rule that applies is the rule that sticks

Whether it's a deny or a pass, if it fits, it sits. So when going down the list from top to bottom, if the first rule that applies to the traffic is a deny rule, the traffic is denied even if there is another rule further down that would also pass it. This makes the order of rules important to keep in mind.

Once traffic is trusted, there isn't a second chance

Unless there's a second firewall somewhere down the pipeline, of course. But speaking in terms of a single firewall handling traffic from multiple networks, the rules for each network interface must be designed around whatever traffic is expected from that network. If traffic from Network A to Network B must be blocked, it needs to be blocked on Network A's interface. Network B's unidirectional rules won't apply to that traffic. (Other means of disabling inter-network traffic can be utilized as well, but I'm referring to the firewall-specific methodology of limiting network access here.)

Setting a source port is rarely ever necessary

If you find yourself setting a source port for something, odds are that you're attempting to do something unnecessary. Source ports are often randomly chosen by an application. The destination ports are the ones that stay static, but the source ports are not usually required to be the same. If you find yourself saying, "But this port is always the same and I want to allow traffic to it," it's more than likely because the visualization of the flow of traffic through the firewall's interfaces got a bit muddled.

To explain a bit further, let's bring up an embarrassingly incorrect thing I tried to do before I realized what was going on. I set an allow rule for traffic on an internal network for a port on local computer running a server. I set the source address for the computer and the source port for the service. Doing this didn't break anything. But it was entirely useless because there was an allow rule immediately below it that would have also applied. But I thought that it might fix a problem I was having with connecting to that service because I was explicitly stating it.

So this hint is not so much about keeping anyone from breaking something. It's more of a bellwether. If you find yourself doing it, odds are good that it's because of an underlying misconception. (Most of the misconceptions that led me to making these types of errors were resolved by the visualization in this article.)

Allowing traffic for a port is not the same as port forwarding

On SoHo gateways, port forwarding is generally a one-step deal. By creating a port forward, the gateway usually creates a firewall and a Network Address Translation (NAT) rule without the end user having to worry too much about the specifics. With more advanced features comes more requirements. Firewall rules and NAT are often handled separately on more capable network equipment.

Creating a firewall rule to allow traffic targeting a certain port doesn't necessarily do the trick for getting the traffic to its destination. That's because computers external to your network are not and should not be allowed to address computers in your local network directly (at least not with IPv4). The device that's connecting to WAN, usually your firewall, is the one that receives the traffic. For that device to know how to direct external traffic to an internal address, it needs to be told how. And that happens in the form of a NAT rule. NAT will actually change the information in the Frame and Packet layers to adjust destination accordingly. (Read here for more information on network layers and TCP/IP.)

It's not just NAT that does the trick, either. First a packet must pass a firewall rule and be considered trusted. Then it needs to be told where to go with NAT.

For local traffic, NAT is not as much of a concern (although it can still be relevant in some configurations). Most of the time, you're able to address another local computer even if it's on a different subnet.

More information about the differences between local and external addressing can be found in RFC 1918, which details the exhaustion of the IPv4 addressing scheme and designates reserved ranges for private use.

NAT is not usually needed for IPv6, but since most current internet traffic still involved IPv4, NAT is a necessary step in directing external traffic to internal resources.

When in doubt, test it and log it

For most of your rules, you probably aren't going to want to log the traffic. Enabling logs for allowed connections can rapidly fill up your logs, and even edge case deny rules can spam a surprising amount if there's an unruly device on your network that insists upon sending out that one annoying packet every thirty seconds.

But for troubleshooting purposes, the enabling logging can give you immediate x-ray vision to see how far through the network a given packet is getting before spiraling into oblivion. Simply set up a rule you want to test, enable logging, send the packet, and check the logs. If the rule generates a log entry, you'll have immediate verification that it's working as intended. If it fails to generate an entry, a different rule is applying to the traffic before meeting the rule you're logging. Check all the things listed above such as rule order and interface direction, change things around, and test again until you're able to generate a log entry.

Once you've got it set up in a way that's working, you can disable logging so it's not clogging up the works with unnecessary verbosity.

That's about it! If I come across more useful things, I might add them on. But I wanted to keep this one fairly short and sweet. Have a good one!

I've kinda been itching for a good excuse to play around with Docker and learn the ropes a little bit. I'm also crazy about Valheim, which just released a big new content update that has been in the works for the past year. I set up a dedicated server for some friends on a spare Windows machine I have lying around. But in my mind, this sort of thing (running servers) feels best in Linux. So I'll be wiping Windows clear off of it and running a few dedicated servers off of Linux.

I have a few criteria specific to my situation that I'd like to accomplish with this setup.

• I want to be able to spin up multiple servers concurrently.
• I want trusted friends to be able to VPN into the network segment to manage the servers as needed. (This machine will run within its own VLAN to suit that purpose.)
• And I'd like to automate a few things to make common administrative tasks quick and painless, even for friends who aren't savvy with command line.

Obviously not all of these thing will be applicable to everyone wanting to run a Valheim dedicated server. So if you've come across this page searching for a straightforward tutorial of Valheim dedicated server Docker images in Linux, I will still try to provide some helpful bits. I'll split up the article into two parts, covering my experience with getting the dedicated server up and running in Docker, then later we'll get into the criteria mentioned above.

Making backups

I migrated this server from Windows to Linux, so I made a backup of all the server files since I'll be wiping the operating system completely. I won't be needing all of the files, since it's going to run as a Docker image, but backed up the entire dedicated server file tree regardless.

If you have an existing world you want to copy over, first determine whether it is stored locally or in the cloud. Since patch 0.209.8, there's an option to use Steam's cloud storage. More information about their cloud storage update can be found in this Steam community post.

Worlds stored locally will be in %UserProfile%\AppData\LocalLow\IronGate\Valheim\worlds_local in Windows or ~/.config/unity3d/IronGate/Valheim in Linux.

Worlds saved on the cloud will be in C:\Program Files(x86)\Steam\userdata\NUMERICSTEAMID\892970\remote in Windows, or ~/.steam/steam/userdata/NUMERICSTEAMID/892970/remote in Linux.

Worlds from a previous dedicated server will be in C:\Program Files(x86)\Steam\steamapps\common\Valheim dedicated server\ in Windows, or ~/.config/unity3d/IronGate/Valheim/worlds in Linux.

If you are unable to find the correct world files in any of those locations, it may only be available through Steam's online cloud storage. Follow this link (https://store.steampowered.com/account/remotestorageapp/?appid-892970), login to your steam account, and you should get a list of all synced world files contained there.

Installing Linux

Now that I've got backups of everything, I'll wipe the OS and get a fresh one up and running. I'm going to go with a Linux Mint build. I've put together a nice comfy look and feel for it that I've grown accustomed to. I wrote a tutorial on putting it together if you're curious about the details.

Linux Mint with a Kali Themed Twist

Some good ol fashioned customization to make Linux Mint just the way I like it... Like Kali.

geekly.devNad

I'll make one note here about swap space. I ran into issues having a large swap partition using ZFS. When spinning up servers beyond what could be supported by RAM, the system would freeze. This was likely due to ZFS compressing the swap space, and running into problems when large amounts of swap space were being utilized by Docker for the containers. There may be ways around this issue, but I opted to reinstall on LVM instead. If RAM is a limitation of your hardware and you foresee the necessity of using a large swap partition from time to time, I'd recommend just using LVM instead of ZFS unless your have a good reason otherwise.

I do recommend setting up a large swap space if your RAM is limited. Swap size can be adjusted after-the-fact, but the method changes depending on if you're using traditional partitioning, LVM, or ZFS. My 8GB of RAM were pretty much entirely used upon initializing the first instance, and about 2-3GB of additional space were needed by each additional server after that.

Installing Docker

With the new OS up and running the way I like, it's time to grab Docker.

Install Docker Engine on Ubuntu

Instructions for installing Docker Engine on Ubuntu

Docker Documentation

I followed the instructions of the official Docker installation guide, but quickly ran into some issues specific to Linux Mint. If you aren't running Mint, the instructions in the link above should work fine for you.

I ran the provided commands to add the Docker repository to apt.

 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

However, when I ran sudo apt-get update I received the following error.

Ign:7 https://download.docker.com/linux/ubuntu vanessa InRelease
Err:8 https://download.docker.com/linux/ubuntu vanessa Release
  404  Not Found [IP: 54.230.21.60 443]
Reading package lists ... Done
E: The repository 'https://download.docker.com/linux/ubuntu vanessa Release does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

This issue is specific to Linux Mint 21, as lsb_release -cs in the command to write docker.list results in the output vanessa instead of jammy. Editing the docker.list file to change vanessa to jammy fixes the issue and allows sudo apt-get update to proceed as normal. Docker installed without a hitch and ran the hello-world container.

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo docker run hello-world

Running the hello-world container is just a simple way to verify that the installation worked correctly.

I added my user to the docker group.

sudo usermod -aG docker $USER

A logout is recommended for this to take effect, followed by running docker -v to test that the permissions are working correctly.

With that working, I ultimately want a separate account for managing all things Valheim because I may want to run other servers on this machine in the future. I want an account that friends can use to run server maintenance when necessary, but I want to keep it separate from other services I may be running in the future. So I created a new user account, set things up the way I like them, and made sure to add the new user to the same docker group.

Setting up directories

I created folders in my new user's home directory for each of the Valheim servers I'd like to run. Each server needs a config and a data directory, and since I'll be using pre-existing worlds, a config/worlds/ folder. From the user's home directory, I ran:

mkdir -p valheim-server1/config/worlds valheim-server1/data
mkdir -p valheim-server2/config/worlds valheim-server2/data
mkdir -p valheim-server3/config/worlds valheim-server3/data

The -p argument tells mkdir to create parent directories if needed. Also, I didn't actually use this naming scheme, and opted for using the names of the worlds instead. Either way works fine. Just be sure to adjust any references as needed.

Migrating worlds

I copied the world data over from another computer with a USB stick. If you're starting a server with a fresh new world, you won't have to worry about this step. Otherwise, scoop up the backups you made earlier and find the world data you want to copy over.

You're going to want the .db and the .fwl files that coincide with the world name you want to copy over. Place the files for each separate world in the corresponding ~/valheim-server#/config/worlds directory.

Creating the initialization script

This can be done with a single command, but depending on what options you want to use for your server, it can get pretty unwieldy to write out. I wrote up a .sh script for each server so that I can edit the options and re-initialize as necessary.

#! /bin/sh
docker run -d \
    --name Docker_Server_Name \
    --cap-add=sys_nice \
    --stop-timeout 120 \
    -p '2456-2457:2456-2457/udp' \
    -p '9001:9001' \
    -v $HOME/Server_Folder/config:/config \
    -v $HOME/Server_Folder/data:/opt/valheim \
    -e SERVER_PORT="2456" \
    -e SERVER_NAME="Game_Server_Name" \
    -e WORLD_NAME="worldfilename" \
    -e SERVER_PASS="BestPasswordEver" \
    -e SERVER_PUBLIC="false" \
    -e RESTART_CRON="0 6 * * *" \
    -e TZ="America/Los_Angeles" \
    -e BEPINEX="true" \
    -e SUPERVISOR_HTTP="true" \
    -e SUPERVISOR_PASS="BestAdminPasswordEver" \
    -e ADMINLIST_IDS="00000000000000000" \
    -e BACKUPS_MAX_AGE="10000" \
    -e BACKUPS_MAX_COUNT="50" \
    -e BACKUPS_IF_IDLE="false" \
    -e BACKUPS_CRON="0 0 * * *" \
    -e BACKSUPS_IDLE_GRACE_PERIOD="86400" \
    lloesche/valheim-server

This is just an example configuration with a lot of details that will need to be altered in order to function properly. Here's basic rundown of why these settings are what they are.

The --name argument provides the reference name for the Docker container. This name can be used with Docker commands such as docker restart name or docker stop name, for example.

With cap-add, we add Linux capabilities to the container. The sys-nice value was provided by lloesche's documentation. More information about privileges and capabilities can be found here.

And stop-timeout sets the stop buffer time to give the container time to shut down properly. A maximum time is set to avoid indefinite hangs, but the default time of 10 seconds is insufficient for gracefully closing out all the components of the container.

Next up, we have port configurations with -p. The left hand side of the : is the outside, and right hand side is internal to the container. If running multiple instances, the internal port can remain default values with only the external port altered. For instance, -p '2456-2457:2456-2457/udp' for one instance and -p '2458-2459:2456:2457/udp' for another. The quotes surrounding the values are recommended by Docker's documentation, but not strictly necessary.

There is also a port mapping for 9001, which is the supervisor HTTP interface (enabled further down). HTTP is a TCP protocol, and TCP is Docker's default value in port mappings unless otherwise specified, so -p '9001:9001' suffices.

Then we'll also want to pass volume arguments to Docker to let it know where it can map certain internal data to external directories. This gives us little windows into the container's filesystem where we can place things like configuration files, world data, plugins, and have persistent storage of the build data.

Setting  the -v $HOME/Server_Folder/config:/config volume enables the container to find our world data (which should be located in ~/Server_Folder/config/worlds) and create any necessary configuration files. Backup data will also be stored in a folder at this location.

Setting the -v $HOME/Server_Folder/data:/opt/valheim volume comes in handy in the case of shutting an instance down, removing it from docker, and re-initializing it with a different configuration. Instead of having to pull down updates from scratch to initialize, it can pull directly from the mounted volume.

Now if you scroll back up and take a look at the initialization script again, you'll see that we have a whole bunch of -e arguments in a row. These are the environment variables that will be used to set configurations of the server.

The first few environment variables are fairly self explanatory. Others, not as much.

• SERVER_PORT doesn't ever really need to change, as it can be adjusted through the container's port settings with -p.
• SERVER_NAME is the name that can show up in-game.
• WORLD_NAME is the name of the files.
• SERVER_PASS needs to be a minimum of 5 characters.
• SERVER_PUBLIC allows for server discovery through Steam. I recommend setting this false unless you genuinely want a public server, as it seems that populating the server list in-game checks connection against each potential server on the list resulting in excessive amounts of connections. Think of it as getting pinged a few dozen times a minute. It's not a huge load, but it's unnecessary unless you actually want to be on the list.
• RESTART_CRON sets a restart timer using cron format. Daily restarts are useful for avoiding server errors and memory leaks that can build up over time. There is another environment variable RESTART_IF_IDLE which has a default value of true. So if players are currently connected during the scheduled restart time, it will skip the restart. I have my server set to restart at a time when people are not usually logged in, but allow the server to skip the restart (by leaving RESTART_IF_IDLE at default true) because missing a daily restart isn't as immediately awful as being caught in the middle of a build and losing progress. If you're unfamiliar with cron's format, there's a handy web tool for entering different values to see the results.
• TZ sets the server's time zone using tz database names.
• BEPINEX is a mod framework. If you aren't using any mods, this can just be omitted completely as the default value is false. If you are using mods, either BEPINEX or VALHEIM_PLUS should be set to true, but not both at the same time. On the first initialization, plugin folders will be created where you can drop in whatever mods you want to install. (Either config/bepinex/plugins or config/valheimplus/plugins depending on which you use.) After copying your mods to the location, you can restart the server to load them with docker restart container_name.
• SUPERVISOR_HTTP and SUPERVISOR_PASS creates a simple web server and creates a password for it that allows you to manage certain functions and check log tails. I would not recommend opening this port to outside your LAN (for instance if you want friends to be able to restart the server) for security reasons. HTTP does not use encryption, and the password does not appear to actually be used even for restarting the server. Allowing external access to this feature will enable anyone on the wide open interwebs to check your logs (including snagging player IDs if present) and stop your server at will. I have actually removed this function from my own servers, but left it in this list as an excuse to mention the vulnerability. I will recommend other means of performing these same tasks instead of using this interface in the second part of this.
• ADMINLIST_IDS passes space separated user IDs to the adminlist.txt file to give admin permissions to users on your server. User IDs can be pulled from in-game using the F2 overlay which displays all currently connected users and their corresponding ID. These IDs can also be pulled from the logs by grepping lines with "Got connection SteamID". Note that the adminlist uses SteamIDs and not in-game player IDs (ZDOID in log entries). Multiple IDs should be presented in the same "" block separated by a space. For example: "01234567890123456 12345678901234567".

Backup scheduling can be a bit of trick depending on your needs and your resources. In my case, I wanted it to mainly update when people are connected, and I have a fair amount of storage to throw at storing backups. Since we often go for months at a time without playing much, the BACKUPS_MAX_AGE is set to "10000" to effectively disable removal of older backups. Instead, I set BACKUPS_MAX_COUNT to store a total of 50. BACKUPS_IF_IDLE="false" makes the backup only run if players are connected, and BACKUPS_IDLE_GRACE_PERIOD="86400" (which is 24 hours in seconds) provides some wiggle room. So if a player has connected within the past 24 hours, the backup will run. BACKUPS_CRON defaults to every hour, but in my case I just want it to back up once a day at midnight so setting the value to "0 0 * * *" works fine.

It's also worth noting that these backups are a compressed archive of the entire world folder. The dedicated server itself makes autobackups on its own schedule, and this separate backup process makes a backup of all of those autosaves as well. For extra integrity, backups can be set to save to a custom location with BACKUPS_DIRECTORY. So backups can be saved directly to a separate drive, for instance. In my case, I will eventually be setting up my server with a RAID1 array to mirror the drive in case of failure.

Finally, the argument lloesche/valheim-server gives Docker the build we're going to use to create the container.

For a full list of environment variables, check lloesche's documentation. Configurations can get even more intricate and use things like log filters, event hooks, Discord webhooks, and configuring plugin variables, just to name a few.

Spin it up!

Once you have a configuration you want to try out saved, make sure to give executable permissions with chmod 744 server_init.sh. It can then be run with ./server_init.sh.

On the first run, the container will be downloaded and it will automatically run updates. Logs of the progress can be run with docker logs Docker_Server_Name. You also may have to open ports in UFW, but at this point you can test to make sure you can connect from another computer on your LAN.

If you find settings you need to change in the initialization, the container can be stopped, removed, and reinitialized.

docker stop container_name
docker rm container_name
./server_init.sh

This is where having the data/ volume mount comes in handy because reinitialization will require a whole lot less.

If your server is set up the way you like it and connections are working locally, it's time to set up port forwarding and firewall rules and have your friends try it out!

In the next part, I'll be going over my own network configuration to describe the other features I'd like to have on my server. While some of them are very specific to my own network configuration, there may be some useful things in there for anyone who'd like to set up remote administration in a more secure way using an OpenVPN server for remote tunnels, FTPS for file access, and SSH for shell access. Link will be added here once it's available.

As always, if you have any suggestions or corrections for me to take into account, please let me know!

This is part 2 of a series, The Strangest Explanation of VLANs You've Never Heard. While it should be largely capable of standing alone, it does build on some of the topological concepts discussed in that article. This should provide what I find to be a useful shift in perspective for understanding and better utilizing the concepts of the TCP/IP and OSI models. I'd recommend reading through the series in order to get the most out of it, as I've tried my best to present idea in the most linear way I could think of.

The strangest explanation of VLANs you’ve never heard

Mental models rarely fit neatly into little boxes, yet we try to visualize them using overly simplistic means. For once, let’s get a little nutty.

geekly.devNad

Physical and Logical

Because networks don't just live in the more abstract world of programming, but also have tendrils that connect out to other physical devices, it's important to examine the concepts that are commonly utilized. Network diagrams, for example, can be designed to convey physical configuration of devices and wiring. Or they can be diagrams designed to convey crucial aspects of logic that define the network topology. It can be confusing to look at a diagram expecting a physical layout when it is in fact a logical diagram.

In a physical network diagram, a gateway router that also serves as a firewall and a wireless access point can be represented by a single node. But on a logical diagram, there might be good reason to want to break out those specific features to their own independent nodes. A device present on a physical diagram might not have any reason to be present on a logical diagram if it has no effect on the topology being described.

Similarly, a router as a physical device can be employed in a use case where it serves the same logical function as a another type of device, such as the above example of a flat network where a router is being employed as a switch. Just because it is a router doesn't mean it has to route. This doesn't have much of an effect on a physical layout, but it can fundamentally alter the logical configuration. This can sometimes be described by referencing which "layer" a given device accesses.

So let's drill down through these so-called layers real quick to find some tools that will help us describe the logical arrangement of networks. For that, we're going to have to take a short dive into the TCP/IP and OSI models.

The TCP/IP model was created as a framework to implement a network protocol and was originally described in RFC 1122 and RFC 1123 (RFCs, Request For Comments, are publications through which many of the standards of the internet are established). The framework describes standards of communication across a network within protocols, and established a model of visualization using layers that is commonly referenced to communicate key features of those protocols.

The OSI model was developed as an updated version designed to break down TCP/IP's layers into more granular components. While the TCP/IP model is implemented in protocols, OSI is more for reference purposes. The numbering system of OSI is most commonly referenced because the extra delineations can be very useful.

Yes, this does indeed lead to confusion. To add to it, the numbering starts at the bottom, but the formation of data starts at the top. Hence my earlier phrasing of "drill down" and "short dive", as the formation of data is the more crucial aspect when it comes to mapping the concepts out.

So how do TCP/IP and OSI stack up against each other?

This is the usual form that they are presented in. The idea behind these is that, starting at the top, an application needs to communicate with another device, and it packages the data it needs to send. More data is added to that to facilitate the transfer. The added data is broken up into groupings defined roughly on the spectrum of software to hardware, or logical to physical. We'll get into more detail on this soon.

I'm not a fan of this representation because it doesn't lend itself well to visualizing how various steps along the way access the different layers. But the comparison is useful for noting the additional delineations of the OSI model, and how they correlate to the TCP/IP layers.

There are "updated" versions of the TCP/IP layers that attempt to add in aspects of the OSI model (differentiating between Data Link and Physical in particular), but in my opinion it's like trying to plug a leak in a swimming pool by throwing a blanket over the top of it. The solution does not address the problem and only succeeds in muddying the water.

The problem with this visualization is that it's layering things on top of each other like a sandwich. What we should be doing is visualizing it in terms of encapsulation. Matryoshka dolls come to mind.

These nifty little doo-dads fit the bill nicely. They are layered. They can be readily disassembled, examined, and reassembled. Each of the layers can stand alone and contains its own unique information. Let's go with this.

The key concept here is encapsulation. When a program is called to communicate with another similar program through a connection, it will first form a payload to send to the remote program. Large chunks need to be broken up into smaller pieces. Those smaller pieces make up the core of a packet. In addition to that core, though, there needs to be additional information to provide to the network that will facilitate its journey. Information like where it's coming from, where it's going, which piece of the whole it is, and possibly some security features that might come in handy. In other words, it needs supplies for the trip. Around the core, these additional layers are encapsulated in a standardized way.

Referring over to the word-shenanigans in the companion VLAN article, encapsulation is akin to envelopment. We're taking a thing and enclosing it within another. And recalling back to our tools of topological tinkering, each subsequent layer of encasement can still maintain its own distinct boundary manifold.

Ultimately, we want that package to travel down along a line, or wifi signal, or whatever other means of transportation is available to it, and find its destination. During the short stops along its passage, it needs to check in with, say, a ticket booth at yonder router. Or it might need to get its port number checked at a firewall. Thankfully, our packet is prepared and organized with all the bits in the right layers. The topological manifolds are consistently correct, otherwise the packet gets "dropped."

In other words, the topology of the packet must be compatible with the topology of the interfaces it passes through. The "shapes" must correspond.

With this, we can visualize an end to end connection. On one end, starting with the core of application data, the packet is encapsulated with layers, sent down a line, received, decapsulated, and handed to the receiving application. What's more, if we shift perspectives a bit and lay this on its side, we can see that the layers still even resemble the classic representation of the stack.

So far, nothing in between the source and the destination is represented yet. But we can start imagining what might be required to fit in. And the taper in the middle, even though it's more of a stylistic feature, gives us another clue.

I'll refer back to the mesh topology exploration in the VLAN article (specifically, Getting Down to Brass Tacks). In that, we took a look at what topological effects would come from pinning a Post-It note to a cork board using a thumb tack. In doing so, the Post-It note and cork board were topologically transformed. Most notably, the note went from being basically scaled cube to having more in common topologically with a torus. It had its boundary manifold fundamentally altered by the process.

In this case, we can picture the data being transmitted as the pin (the topology that defines the rest), the devices on either end of the connection as cord boards (terminal end points that have topology that conforms to the defining topology), and network devices along the way as Post-It notes (acting as passthroughs).

So what about frames and packets, then? These simply refer to the hierarchy of data within layers as they traverse through a network. Communication between devices on a network happens in a stream of bits. Different devices examine different aspects of the data and make decisions about what to do with it.

Some devices only look at a portion called a frame. Frames coincide with the Link/Data Link layer, on the TCP/IP and OSI models respectively. The frame contains hardware address information about where it's coming from and where it's going to. The hardware address is also called a MAC (Media Access Control) address. These addresses are used by layer 2 (using OSI numbering) devices. Layer 2 switches are one example, but physical interfaces in general are layer 2 devices meaning they access the stack up to and including layer 2.

Other devices are capable of examining the packet level, which corresponds with the Network/Internet layer. This layer contains IP address information. While hardware addresses aren't intended to leave a local network, IP addresses are used for routing through the internet as a whole. The key takeaway from the delineation is that two sets of addressing schemes are used. One for local, and one for global. Layer 3 (OSI numbering) devices are capable of inspecting these addresses in order to route traffic to the correct destination.

Firewalls need access to the transport layer, also known as segments, so they can be considered layer 4 devices. And there are even some network appliances that examine the application layer, such as some intrusion detection systems and certain types of proxies. So all the way through the stack, we can potentially have equipment that can interface with all of it. (Note that this doesn't necessarily imply that your data is being read every step along the way. The application layer is commonly encrypted, or at least should be. But use of encryption doesn't imply that data is unreadable. That's a topic for another article though.)

Let's take a quick look at how this is usually represented, and see if we can get it to mesh well with our working model.

The feature I'd like to draw the most attention to is the usage of vertical columns. Starting at the top with the Data block, if we follow that down through the layers, we can see that it stays in place. It just becomes increasingly encapsulated as it goes. In the Segment layer, the UDP Header gets tacked on. In the Packet layer, it gets an IP Header. And in the Frame layer, it gets a Frame Header and Footer. But all through that process, the Data block persists in its place.

This view of the layers is actually what gave me the idea of Matryoshka dolls in the first place. It adds an extra dimension to the one-dimensional layer ordering by providing the columns to show the encapsulation. From this, I simply added another extra dimension to show transit of information. So this fits in nicely.

We do lose a little bit of information in the translation here. This is due to the principle mentioned in part 1, "Simplistic diagrams are limited to simplistic concepts." We lose details about the frame containing both a header and a footer, for example. There are other details about the original diagram that lend themselves better to visualizing the encapsulation in terms of the bitstream, as well. For the purpose of this visualization, however, those details are somewhat extraneous. We are aiming to visualize the stack as it moves through a network.

So let's take a look at how this might fit into a network device.

There's quite a bit to take in here. The main components to take note of are the data streams, outer ring, inner core, and linkages. These are just informal terms we'll temporarily use for the abstractions we're translating. Let's take another look from the top and break out the individual components.

The data streams are easy enough. Those are all of the incoming/outgoing connections to other devices on this network. Even when we're looking at it from the top like this, we can still discern the stack of layers.

The inner core represents the connectivity between data streams. It's a way of showing that these data streams all have potential to be passed along. In other terms, this shows the connections are within the same broadcast domain.

The outer ring represents the device's interface to the data stream. All network devices perform some sort of programmatic operations on the given data stream to varying degrees, and this is where those operations are performed. For this example, our outer rings have four layers, implying they are accessing all layers of the stack. We'll look at other examples shortly.

The complicated looking tech-snowflake in the image above is comprised of the linkages. The linkages show how the data stream is interfaced by both the outer ring and the inner core. They're the topological features that connect everything together in an orderly fashion. And since the objective of this exercise is to visualize topology of the flow of data through the devices within a network, this strange little snowflake is the star of the show.

This "completely decked out" example of the device accessing all the layers isn't particularly common though, and feels a bit stifling. So let's take another look at it in a different context.

In this example, the outer rings only access the link layer (layers 1 and 2 of the OSI model). So this could easily represent a network switch that only needs the link layer to do its job.  There is only a single set of linkages connecting the data stream to a single set of outer rings.

But when we look at the inner core, we can still see that the information that gets passed through to other connections still contains all layers of the stack. The inner core itself retains the features for all of the layers, and the linkages are still present. That's because the data stream going through this node is not diminished by it. While the device might be able to read and possibly alter aspects of the link layer, the stack as a whole still passes through.

So let's take a look around what a layer 3 device would look like, and what it might be capable of doing.

The outer rings now have an additional feature to illustrate the addition of a layer, as well as another set of linkages to the data stream to match. This layer 3 device (again, up to and including layer 3 of the OSI model, coinciding with the Internet layer of the TCP/IP model) would be capable of accessing both the MAC hardware addressing information from the Link layer as well as the IP addressing information from the Internet layer. Such a device is likely performing some sort of routing function.

This model would work well within a flat network, but what about cases of networks using subnets or VLANs? Could we add in more central cores to illustrate network segmentation? Perhaps we could expand the design vertically and make a stack of stacks.

This vertical stack is an intriguing idea. We'll get more into that later though. First, let's go into a little bit more detail about the relationship between the outer rings and the inner core, the processes that we can attribute to them, and the limitations of this model.

Broadcast domain interconnectivity is an essential component of network topology. That "inner core" of our imaginary network device is effectively acting as what's known as a bridge. Bridging is a mechanism for ganging network interfaces together into a pool.

This is where it gets tricky, using simplified models to represent what's going on though. Because we separated the concepts of device logic and interconnection, we also have the implication that the device doesn't perform logical operations on connection states, which is not at all the case.

Recalling back to a previous concept in the series, we went over the idea of a switch as a sprinkler head. I joked about hooking a hose up to a port and having water spray out of all of the other ports, and I mentioned the idea of "gates" controlling the flow into and out of the switch.

Hook up a hose, plug two of the holes, and the water will spray out of the remaining hole.

This is largely the logic being performed within the device. Whether and what to pass along, and where to pass it to. So while the block above can also be thought of as a bridge of sorts, it lacks any topological features to indicate the logic of functions.

Looking again at our imaginary network device monstrosity riddled with topological linkages, we can envision this process to a certain degree. Let's look at one last set of examples of it to simply things a bit more.

This device is hooked into the all the layers up to the transport layer, so it would be referred to as a layer 4 device (layers 1-4 of the OSI model). So this could be a firewall, for example. Firewalls need to examine the transport layer for port data, which enables them to selectively allow or deny traffic based off the set of rules they use.

I depicted only two data stream connections here to simplify matters a bit so that we can visualize the flow of data in strictly linear terms. So let's say that the data coming into the firewall is from an upstream connection in the upper left. It is inspected by the device, accessing up to the transport layer, and passes the rule set to subsequently be passed along (if it didn't pass, it would be dropped right there and then). From the inner core, there is only one other connection it can go. On its way back out of the device to the lower right, it is then inspected again to ensure that it passes the set of rules.

Now we've got the same deal, but with two downstream connections. After the data is passed through to the inner core, it then goes out to both connections. Let's say the connection to the right is the correct destination, while the connection lower down is incorrect. The destination will be examined on the way out of the device. For the connection to the right, the destination will be verified to be correct and passed along to proceed to its destination. If it's incorrect, as in the case of that lower connection, it will get dropped, never be received by the far end of the connection.

This explanation allows for the separation of those concepts of device logic and interconnection. It's important to note, though, that thinking of the device logic and the bridge as being separate does not always play nicely.

Mikrotik's Packet Flow chart is a great example of how these simplifications can be rendered insufficient in short order. But as a general mental model, this kind of visualization has helped me significantly to grapple with more complex details as I come across them. While simplified models are rarely ever perfect, they can be useful tools for understanding specific elements of a complex system.

In the next and final part, we'll head back to take another look at the SSFBSGLSWT (strange sci-fi Battlestar Galactica lookin' sub-woofer thing) and why I made such an odd thing to begin with. Hopefully, you've already got some guesses as to the meaning behind of some of its odd features.

Link will be available here once it's published. Until then, and as always, if you have any suggestions or corrections for me to take into account, please let me know! I tried to make this as orderly as I could, but whether you're an experienced technical engineer, just starting out, or simply reading through out of curiosity, if you feel that there are any sections that need improvement I'd appreciate the feedback.

This is the first part in a series of odd explorations and exposition with the intent of providing a fresh take on the subjects of VLANs, subnets, cross-discipline topology, network protocols, and mental models by altering visualization techniques to make the concepts more approachable to the uninitiated and more engaging to experienced engineers.

You might have a good idea of what VLANs are, already. You might know them more thoroughly than I do. Or perhaps you've never even heard of them before. Whatever the case may be, I'm fairly certain you will have never come across an explanation of them remotely as weird as what I'm going to offer here.

I recently spent a decent amount of time deep diving on VLANs, and I got a bit frustrated with the explanations I came across. They did the job well enough. The explanations conveyed the concepts, but they felt incomplete. I had difficulty forming a mental representation of what was going on. And I noticed a disparity of information between the baseline explanations and the explanations that were so incredibly in-depth that they required hours of mulling over flow charts of hardware level packet handling in order to understand. There wasn't a whole lot in between.

I talked about this effect a bit more in another post, The Many Labyrinths Interpretation.

The Many-Labyrinths Interpretation

Bridging the gap between superficial knowledge and practical understanding can be downright overwhelming. Why?

geekly.devNad

In that, I suggested that offering the details of one's learning experience, though they may differ from others', can be a vital aspect of overcoming the disparity of information available in the void between superficial understanding and deeper comprehension. While a deeper comprehension of VLANs is beyond the scope of this strange little thought experiment, I hope to at least provide some context from my own experience in a way that would move that deeper comprehension within reach.

If you're new to VLANs and wondering what the heck is going on here, I will do my best to explain them as I understand them shortly. Before that though, I just want to lay some groundwork and provide some context as to why I would bother making a sci-fi rendering of a strange Battlestar-Galactica-lookin'-subwoofer-thing.

Diagrams and charts enable succinct visual representation of concepts, but they have inherent limitations. In simplifying complex ideas into straightforward representations, a degree of complexity is summarily discarded. Often, that degree can be a significant amount. Sometimes complexity is unnecessary to convey the idea being presented. Other times, crucial information is lost in translation.

This leads to a simple measure: Simplistic diagrams are limited to simplistic concepts.

Making diagrams that contain more information leads to design issues. How can additional information be presented in a way that doesn't clutter and obfuscate? Our mental models of systems can process and contain a wild amount of information, but they largely consist of abstractions that prove difficult to communicate.

Learning something new requires building new mental models.

We tend to build those mental models using the descriptions, visual aids, and whatever scraps of information we can piece together into a coherent image. However, when the information available is scarce, the visual aids are overly simple, and the descriptions fail to paint a picture, it can be a frustrating experience.

What I'd like to attempt in this bizarre exercise is to present the key concepts that helped me to understand underlying network structures using imagery and visualizations along common themes. If simplistic diagrams are limited to simplistic concepts, that's fine. We can break down complex ideas into simpler ones and visualize them as we go. Keeping consistent themes across the different types of visualizations will help transfer comprehension between concepts. At least, that's my hope.

In basic terms, VLANs (virtual local area networks) are a way to virtualize additional hardware connections with low level software. Creating VLANs is a way to divide the network into virtually isolated segments, and to enable rule based policies to determine how those network segments are allowed to communicate with each other. And it does so using a minimal amount of physical hardware and connections. A simple tag gets added to a packet within the frame that enables network appliances to make determinations about how the packet is handled on both the data link and network layers.

If anything in that explanation strikes you as previously undefined and confusing, don't worry. We'll get into the details of all of it. It's a juggling act to try to explain tech concepts from basic principles because there are inevitable junctions at which many ideas must be introduced concurrently. To some, it might feel unnecessary to explain the basics, while others might feel left behind by glossing over an idea too quickly. I will do my best to present these ideas in a way that's readily accessible for as many backgrounds as I can without using the same dry, rote explanations that experienced technicians are accustomed to. My hope is that providing an unconventional approach to a standard topic will provide something to chew on for all readers alike.

I'm also going to include a quick disclaimer that the point of this exercise isn't to denigrate the value of existing explanations and models, but to try to offer a shift in perspective of how to think about them, and by extension, different considerations for network topology. While I offer my own interpretation of concepts that I feel are usually problematically presented, others might be able to come up with completely novel interpretations. Or they might not agree with the problematic premise to begin with. For all the myriad use cases and all of the different approaches to mapping them, some are going to be objectively good and some aren't. In other words, my offering here isn't of a solution to a problem, but rather an elaboration of my own mental model that helped me to understand certain concepts.

“Begin at the beginning," the King said, very gravely, "and go on till you come to the end: then stop.”
- Lewis Carol, Alice in Wonderland

The biggest stumbling block for me in learning about VLANs wasn't with the basic explanation. I understood the concepts and they're easy to convey. The thought that kept going through my head as I was banging my head against the wall was "what's in the box?" Those little boxes that represent a switch or a router, where lines are drawn to and from that represent connections contained no information about what happens to process those connections. And that's the part that varies heavily between implementations. My SSFBSGLSWT (strange sci-fi Battlestar Galactica lookin' sub-woofer thing) is my attempt to convey the mental model that I developed to facilitate comprehension of those different implementations.

Hopefully it does the job a little better than this.

Kidding aside, this is a useful diagram for describing what's known as a "Router on a Stick" (RoaS), and is almost a useful starting point for describing VLANs in general. But we still need context of what a VLAN is to begin with. So let's talk topology real quick.

Topology is a whole field of study unto itself that has a staggering array of useful applications. A quick look through the introduction of the topic on Wikipedia gives the impression that this is the stuff of Escher-esque brain teasing visual anomalies and maniacal space-time continuum sci-fi shenanigans. It credits Leibniz's Analysis situs and Geometria situs as being foundational works upon which the field of topology was developed.

And as an interesting side note, Leibniz created the stepped reckoner, a prototype mechanical calculator which could perform the four basic arithmetic operations, in the late 17th century. I'm including this little "fun fact" because physical models of abstractions is the ongoing theme here, and the stepped reckoner is a great rabbit hole in that vein.

In short, topology is the sort of thing to give you the means and methods to both completely lose yourself and find your way back out. I won't be going into much depth on the subject, but I want to introduce a few key concepts from it because there is relevance in both networking and 3d modeling. "Network topology" is used often and widely in networking to refer to the in situ configuration of devices and connections within a given network. And "mesh topology" is used often and widely in 3d modeling to refer to the in situ geometric features and "flow" of the polygons that compose a given object.

In both cases, the common usage is very informal. Which is to say that the concepts involved don't require getting into much mathematics in order to comprehend. Instead, let's start with an approach of play on words. Since it's informal, let's talk about informing and deforming.

The first thing that might come to your mind with informing is the concept of being informed of something. When informed, you might interpret, incorporate, and integrate the information. These words all share a common etymological root because they all deal with a similar concept of one distinct abstraction absorbing another. Maybe you have imagery floating around in your head now of one amoeba enveloping another to devour it. That is a useful visualization because it describes an envelope, a manifold encompassing another thing, as a boundary that exists between the two things prior to absorption.

This also gives rise to the concept that in order for the two abstractions to merge, there is deformation that occurs. And we can picture it happening both through the process of involution (as the boundary is obliterated and the abstractions intermingle) and within the final product (perhaps even being greater than the sum of its parts) by using that same amoeba imagery floating around in your head.

While envelopment describes closing something off within a boundary, development describes the removal of that boundary and the deployment of the contents.

Visualizing things in this way, we're able to start thinking about abstractions in terms of their manifold boundaries, what features define them, and what deformations are necessary to accommodate additions and subtractions to and from them.

Getting down to brass tacks

or, A Description of Basic Topological Principles Using the Geometry of Pinning a Post-It Note to a Cork Board

I like visualizations almost as much as I like to mess with idiomatic expressions. We'll be getting back around to applying all of this to VLANs soon, but I just want to put those topological tools to use in something a little less nebulous than amoebas. So let's take a closer look at these so-called "brass tacks" of infamy.

Right off the bat, we can see a few defining features of this tack. Mainly, a domed top with a lip around the edge, and an extrusion from the underside that tapers to a point to form the pin. We can also see the "flow" of the mesh. Because it's largely composed of concentric quadrilaterals, we can follow the order of vertices from one to the next in an orderly fashion along two axes. In turn, this provides the ability to form "loops" that can circumnavigate the object. For instance, the very outer ring can be clearly seen and visually followed. Along the other axis, you can follow a line traced originating from the top of the dome down to the tip of the pin.

The topology of this object is straightforward, easy to read, easy to manipulate, and works well "under the hood" of the rendering engine.

Which leads to the question of what a messy topology might look like.

The object is still basically the same shape, but the mesh topology is now completely different. Orderly topology is starting to look very appealing in comparison.

At the risk of ending up going off into the weeds, this sort of operation, called "decimation", serves a purpose and can be used very effectively to reduce the amount of polygons used to define an object. But this is usually a final step once a mesh is complete, and not something to be done mid-project as it makes modification very difficult. This doesn't have much to do with where we're going and is only included for anyone asking "why on Earth would anyone want to do this?"

Now use this tack to pin a note to the board.

This involves three distinct objects. While the tack doesn't really become altered in this process, the note and the board both go through deformation and have fundamental changes made to them.

The note now has a hole punctured through its manifold boundary. What started off as basically a squished cube is now more akin to a torus because of that alteration. In order to visualize this, imagine being microscopic and walking along the surface of the piece of paper without the hole. When you get to the edge, you take a step and flip over to the other side. Now with the hole, there is an additional feature where if you step through, you'll flip to the other side. Topologically speaking, this surface now behaves more like a torus than a cube. All because of an alteration that we normally wouldn't even bother thinking about in the course of pinning a note to a board.

Something that's also noteworthy is the addition of geometric features surrounding the hole in order to reinforce and stabilize its local position. Without those added "loops", the alteration would affect a much larger area and potentially distort the curvature or flatness of the surrounding area.

Let's take a look at how the cork board fared its alterations.

The hole made in the cork board doesn't extend all the way through, so we didn't end up with another torus this time. However, if we zoom way out and take a look at the whole board we'll find that the changes made to the simple squished cube extend all the way around it now. The "loops" required to define the feature add quite a bit of complexity to what was previously a simple geometric primitive.

Let's take a step back now, because it probably feels as if we've gone pretty far off the course of talking about the things that we'd like to understand. Instead, we've been talking about 3d models and idiosyncrasies of wireframe meshes. The important thing to keep in mind is that creating viable models of abstractions can be a bizarre and difficult undertaking, and that concepts can have more portability than what may seem immediately apparent. By that, I mean that lessons learned in one field can often be applied elsewhere if we just find the right perspective to view them from.

So let's talk networks.

Network topology is usually presented using a Visio diagram, or something similar, with maybe a few footnotes to act as mortar. Diagrams can be incredibly useful. But some can be outright baffling.

Also, let's face it: Most network diagrams are hideous to look at. Instead of scouring the interwebs for a suitable example, I've whipped up a homebrew set that suits my own tastes a bit better.

These are the most often seen components in a basic network diagram. There are a range of other symbols to denote other pieces of network appliances and nodes. Network diagrams can have extensive component sets, but this sampling should suffice for our purposes.

Starting with servers and hosts, these are normally simple end points. They share some similarity to the cork board. The additional feature created (the pin hole poked partway into them) is the connection to the network. But generally speaking, these devices don't act as "passthroughs". They generally have a single point of connection through which all communications travel.

Next up are switches. Switches are similarly simple, except instead of a single point of connection, they have many. There isn't a lot of decision-making involved, though. A switch will retain a list of hardware addresses (also referred to as MAC addresses, which is a series of 6 bytes in hexadecimal that looks something like aa:bb:cc:dd:ee:ff) of the devices connected to it, and when it receives a packet with a MAC address it's familiar with, it sends it along to that device.

Topologically, the most complex of this set is the router. That's because routers are capable to varying degrees of defining and directing the flow of traffic. This is in contrast to switches because instead of just keeping track of MAC addresses, they are also capable of defining and keeping track of IP addresses (which is a series of 4 bytes of decimal that looks something like 255.255.255.255).  

To visualize how a switch's topology might map out, tack a few pinholes into the switch (no, not literally!) that actually connect through to each other. So you could picture a chamber on the inside that the hole pierce through to.

Say we pipe this form up to a water hose (no, don't connect your actual switch to a water hose!), and turn the water on full blast. It's easy enough to imagine a spray coming out of all the pinholes that aren't hooked up to the hose. Awesome. We have a sprinkler now.

Except this isn't exactly how switches work. For a more realistic interpretation, we should also visualize a set of gates that can control which pinholes are open at what times. Sometimes only a pair of gates are open, sometimes all of them can be open.

However, these extra gates aren't exactly a necessary visualization. For our purposes of defining network topologies, we're most interested in understanding the "broadcast domains" of the network. The times when all the gates are open are for packets being sent to the destination of broadcast domain. In plainer terms, it's possible to address all devices on a local network with this special destination address. In IP addressing, the reserved destination address for broadcast packets is 255.255.255.255, and in MAC addressing is ff:ff:ff:ff:ff:ff.

Broadcast domain transmissions are sent to all devices within the network equally. Since any device can send broadcast domain addressed frames/packets, and a switch will readily allow their transmission, any devices located within the same broadcast domain should be considered part of the same flat network.

For routers, we're not going to be able to make such a simple model.

While superficially they serve a very similar function to switches, concatenating multiple connections into a single upstream connection as well as passing local traffic to the appropriate destination, they are generally capable of performing many more functions. Those capabilities can be utilized on as as-needed basis. In certain situations they might be employed to function more or less the same duties as a switch, while in other situations they might be needed to host a significant array of services that add complexities to the network topology beyond what can be represented with a simple intersection of tubes.

This leads to black box scenarios where footnotes are needed for elaboration upon the details of the services present that may affect topology. And in a lot of network diagrams those footnotes are simply absent, leaving the interpreter guessing which of the myriad scenarios apply. So while network diagrams can be very effective and succinct at conveying network structure, organization, wiring configurations, and addressing schemata, they can easily fall short of the mark of truly conveying network topology to succinctly convey the configuration states of the devices.

Since routers are much more context dependent, let's look at some contexts, starting with a simple "flat" network.

Adding some mortar to the brick to make it stick and giving some quick footnotes is pretty easy with this one. The devices connected to the router are all on the same local network. Let's call it a 192.168.0.0/24 network.

The /24 is a CIDR (Classless Inter-Domain Routing) designation used to simplify addressing schemata that means, in this context, that the devices will be assigned local IP addresses ranging from 192.168.0.1 - 192.168.0.254. The addresses are assigned by the router itself with a DHCP server. A DHCP server is a decent example of one of the services that routers can perform that switches generally do not.

What's most important to our ability to define the topology is the knowledge that all of the devices are located within the same broadcast domain. Unless the router's firewall (another relevant service) has rules to specifically prohibit certain connections, each of these devices should be capable of finding and communicating with each other.

Also of note is that I used a different color to delineate the local network downstream from the router from the upstream connection. This may seem like an unnecessary distinction now, but it will become more relevant as we add more complexity into our examples.

Already, our flat network is getting difficult to read, topologically speaking. If not for the fact that all of the local connections are labelled blue, we'd be left wondering what the specific configuration of that second router might look like. Is it masquerading the devices behind it, performing NAT, and defining a different subnet? In this case, no. We still have a flat network. All of these devices are still on the same local network, and are all capable of discovering and communicating with one another.

Maybe the router is performing another service. Maybe it was included simply because it has the potential to perform another service. For whatever reason, the person who made the diagram (hey now, don't look at me like that!) decided to label the device in that location as a router even though topologically it's performing the same function as a switch. The intention underlying the formulation of the diagram may be obvious to the creator of it, but can easily lead to unintended ambiguity for the readers.

What would a network look like that isn't flat? For that, we're going to go back to our simple flat network and reconfigure the router to serve some different subnets.

Subnetting is a way to isolate networks from each other by defining different IP address ranges. This limits the scope of the broadcast domains for each subnet. It's then up to the router whether to allow or deny traffic between them.

In our example above, our subnets are delineated across the third octet. The red network uses 100, purple uses 110, and blue uses 120. Depending on the configuration of the router these devices might be able to talk to each other or not. For example, we might want the blue network to be able to provide services to both the red and purple networks, but not talk beyond the router to the green network. And we might also want to keep the red and purple networks from talking to each other at all, but to be be able to access the blue network and break out to the internet on the green connection.

Unfortunately, this diagram doesn't tell us much about the internal state of the router. We can determine that it's providing three different subnets, but we can't tell how those subnets mesh with each other.

Let's take this a step further and get a little wacky with this.

We've got some devices grouped by physical proximity. And we have connections labelled according to subnet. The thing is though, we have some mixed and matched associations going on. The blue section is nice and straightforward, but the other two have devices connecting to each different subnet as needed. So in this case, we have to run those connections back to the appropriate switches that serve a given subnet. Another option might be to have a multitude of switches for each location. This might be a preferable approach if we have much more devices.

This is where VLANs come in handy. Remember that first diagram we briefly looked at of a Router on a Stick? Let's apply that to this scenario.

This cleans things up quite a bit. Now we have localized wiring within each group while maintaining access to the variety of subnets. We have a hierarchy that is much easier to visually follow.

This also changes things up quite a bit. Now we have switches with different subnets being served from them, as opposed to routers as we'd expect to see performing such a function. We also have strange rainbow colored connections between the switches and the router.

The thing that makes this all possible is the VLAN tag. This is a simple little mayfly of a sequence of 2 bytes tacked on ephemerally by routers and switches. This tag lets the other routers and switches know which VLAN the traffic is intended for. The tag only stays in place within our local network between the switches and the router. The presence of these tags create what are called "trunk lines." On our diagram, the trunk lines are indicated with the rainbow colored connections.

The tags don't make it all the way to the host machines on the network. Nor do they leave to journey out into the wilds of the interwebs. These mayflies are created and removed by the switches and router, and never venture further than the trunk lines. Their lifespan is not much longer than a handful of milliseconds. Their sole purpose is to pass the VLAN information from one network device to the next.

So VLAN tags give us the ability to create trunk lines, and trunk lines allow us to drive multiple subnets through a single connection. This opens the door on a lot of possibilities that, while they may not have been previously impossible, would have been difficult or costly to implement.

Oh hey, you're still here!

That'll just about wrap up this section, but while we may now know what VLANs are, we still haven't gotten into how to fit these pieces together topologically. There is still plenty more ground to cover, so I've decided to split this up into more manageable pieces before it gets away from me entirely.

The goal of Part 2 is to provide an explanation of the concepts of TCP/IP and OSI layers, frames, packets, and the distinction of physical and logical models. If any of these concepts are completely unfamiliar to you, it might be worth giving it a perusal before we dive into more details about VLANs. It uses the topological concepts we explored earlier to establish a visual model that integrates nicely into all this VLAN stuff.

Visualizing the Layers of the TCP/IP Model

This is part 2 of a series, The Strangest Explanation of VLANs You’ve Never Heard. While it should be largely capable of standing alone, it does build on some of the topological concepts discussed in that article. This should provide what I find to be a useful shift in perspective

geekly.devNad

Part 3 will put a bow on this whole eccentric array of exposition by bringing in the Battlestar Galactica Subwoofer once more to tie it all together.

If you have any suggestions or corrections for me to take into account, please let me know! I tried to make this as orderly as I could, but whether you're an experienced technical engineer, just starting out, or simply reading through out of curiosity, if you feel that there are any sections that need improvement I'd appreciate the feedback.

I absolutely love working in Kali. I used to play around with it a lot back in the days of Backtrack, and it was much more rough around the edges. So when I jumped back into using the more modern Kali, I was blown away with how cleanly everything was laid out. Especially the terminal. It's beautiful and downright capable. But I don't always want to load up Kali just to work in a Linux environment I like.

When I made this site, I decided to make a new designated VM Linux build for handling everything related to managing Geekly. I decided to give Mint and spin, and liked it well enough. Except I really missed the look and feel of Kali (especially that terminal!). So I set out to bring over all the things that I liked from Kali, without the 1337hAxOr tools. The end result is a build of Mint Xfce that feels nice and comfy, where I can code away in peace and serenity.

If this sounds like your kinda jam, I've put together a little tutorial to walk through the whole process.

First ingredient: Fresh Mint

First off, you're obviously gonna need to install Mint if you haven't already. Specifically, the Xfce Edition.

Download Linux Mint 21 - Linux Mint

Linux Mint is an elegant, easy to use, up to date and comfortable desktop operating system.

Linux MintLinux Mint

This was all done on Mint 21, so your mileage may vary if there have been significant changes between when this was written and when you're reading it.

Guest Additions for VirtualBox

If you aren't running this Mint build as a VirtualBox VM, you can skip this section. It's not even strictly necessary even if you are (I've included links to all the required files so that having a Kali machine isn't even necessary), but it just makes life a little easier and I like to do it right off the bat when I create a new VM (unless I want it to be sandboxed and isolated, but that's a whole different tutorial). But it's quick and painless enough to include here, so if you're running this build on VirtualBox, you'll probably want to install the VB Guest Additions to make your life a little easier. It will allow you to share folders and clipboard data between the host machine and the VM.

You can do this by going to the VM menu under Devices, and clicking the "Insert Guest Additions CD Image".

Open up a terminal and locate the mount location. In my case (with a username "mint") it was /media/mint/VBox_GAs_6.1.38/, in which case the command to install would be sudo /media/mint/VBox_GAs_6.1.38/VBoxLinuxAdditions.run. Restart after that and you should be able to enable clipboard copy/paste between host and guest, as well as shared folders. Those options are all available under the same Devices menu shown above.

Did you update && upgrade yet?

Even after a fresh install of the latest release, there are usually still quite a few patches to go out and grab. A simple sudo apt update && sudo apt upgrade will do the trick.

Main Kali Theme

Next, let's grab the Kali theme files. Download and extract to a location of your choice. We're just gonna pick through and grab a few select configurations.

Kali Linux / Packages / kali-themes · GitLab

kali-themes packaging for Kali Linux

GitLab

I'm going to assume you've downloaded your copy to Downloads and extracted its contents to kali-themes-kali-master, so the path to the extracted files would be ~/Downloads/kali-themes-kali-master/.  You can put it anywhere you like, but the commands to copy files from this will have to be modified accordingly.

Copy the Kali-Dark theme and icons and set permissions:

sudo cp -r ~/Downloads/kali-themes-kali-master/share/themes/Kali-Dark/ /usr/share/themes/Kali-Dark
sudo cp -r ~/Downloads/kali-themes-kali-master/share/icons/Flat-Remix-Blue-Dark/ /usr/share/icons/Flat-Remix-Blue-Dark/

We want to set the permissions for files and directories separately.

sudo chmod 755 $(sudo find /usr/share/themes/Kali-Dark -type d)
sudo chmod 644 $(sudo find /usr/share/themes/Kali-Dark -type f)
sudo chmod 755 $(sudo find /usr/share/icons/Flat-Remix-Blue-Dark -type d)
sudo chmod 644 $(sudo find /usr/share/icons/Flat-Remix-Blue-Dark -type f)

Then we're going to want to update the icon cache.

sudo gtk-update-icon-cache /usr/share/icons/Flat-Remix-Blue-Dark/

Let's also grab the system fonts while we're at it.

sudo apt install fonts-cantarell fonts-firacode

Note: if apt is unable to locate the packages, you may need to add the universe depository and update with sudo add-apt-repository universe and sudo apt update.

Open up the Settings | Appearance menu, and select the Kali-Dark theme in the Style tab, Flat-Remix-Blue-Dark in the Icons, and Cantarell 11pt with Firacode Medium 10pt in the Fonts tab.

We'll also want to open up Settings | Desktop Settings and "Configure Xfwm4" to recognize the Kali-Dark theme.

Task Bar Layout

I've liked the top-bar layout in Kali, but I also ended up liking the bottom-bar configuration for Mint. Maybe it helps me more readily differentiate what environment I'm in when I'm switching back and forth between VMs. But if you end up not liking the bottom layout, you can change it.

Uncheck the Lock panel option and hit close. This will give you little handles on the far left and right sides with which you can drag the entire panel up to the top.

You can also add the workspace manager if you like working across multiple desktops to keep things organized. Just open up the panel menu again and hit Add New Items. Way down at the bottom, you want to add the Workspace Switcher. Once it's on there, move it into place where you like it.

Kali uses numbered buttons for the workspaces.

To recreate that, right click on the workspace widget and open up the properties for it.

Set appearance to "Buttons" and rows to 1. Then open up the Workspace settings and replace the verbose names with just numbers.

I personally prefer a different setup using the miniature view because it shows me the window arrangements currently on the workspaces, and I can drag windows between them easily.

If you'd prefer this setup as well, it's as simple as changing the properties over to Miniature View and setting the number of rows to 2.

You can also add separators to your liking. Remember that when you add new components to the panel, they'll show up on the far right. So if you've added a bunch of separators and they're just not showing up, be sure to check over there. They can be easy to overlook.

The star of the show

The next bit is one of the main features that I wanted to bring over. I love the look and feel of the terminal in Kali. And I was a bit bummed that it didn't magically show up the way I liked it when I copied over the theme files. Bummed, but not surprised.

The default look of the Mint terminal just... ain't my thing. It's not that it's bad. But look at it next to the Kali terminal and tell me what you think. (Hint: I will only accept answers pontificating on the magnificent aesthetics of the Kali terminal over those of the Mint terminal.)

I'm glad you agree. Let's fix this.

Thankfully, I found this thread which led me in the right direction. Forum user f33dm3bits did most of the legwork on figuring this out. I'm going to deviate a little bit from those instructions, but the gist is the same.

Getting Kali's terminal just right will take a few things. Qterminal, zsh, some files, and some tweaks to get it all clicking together.

That glorious font is called FiraCode. It's a monotype font with ligatures (meaning symbols like == and =/= have special renditions) and some very slick choices in text alignment that are chef's kiss. We already installed it earlier, so it'll be good to go. But if you're interested in what it does, you can read more about it here.

GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures

Free monospaced font with programming ligatures. Contribute to tonsky/FiraCode development by creating an account on GitHub.

GitHubtonsky

Now let's grab zsh and qterminal.

sudo apt install zsh qterminal

We'll want to grab ~/.zshrc from Kali and bring it in to Mint.

etc/skel/.zshrc · kali/master · Kali Linux / Packages / kali-defaults · GitLab

kali-defaults packaging for Kali Linux // https://kalilinux.gitlab.io/packages/kali-defaults/

GitLabdaniruiz

You can do this by copy/pasting into an editor, or by downloading it and moving to the home directory. In my case, it downloaded as index.zshrc so I just did mv ~/Downloads/index.zshrc ~/.zshrc and chmod 644 .zshrc to set the correct permissions.

Then we'll want to change the shell over to zsh:

chsh -s /bin/zsh

Then log out and log back in.

Looking better already. Still got a bit left to do, however.

The forum post describes using the following lines at this point:

autoload -Uz compinit promptinit
compinit
promptinit

However, the .zshrc from Kali already contains autoload -Uz compinit and compinit -d ~/.cache/zcompdump. I'm not sure if promptinit is required to achieve the same prompt behavior, but there's no harm in including those commands despite the presence of compinit in the config file.

We definitely want to grab the autosuggestions module though.

sudo apt install zsh-autosuggestions

Now let's get ready to switch over to qterminal. First, let's copy over the color scheme from the Kali theme files.

sudo cp ~/Downloads/kali-themes-kali-master/share/qtermwidget5/color-schemes/Kali-Dark.colorscheme /usr/share/qtermwidget5/color-schemes/Kali-Dark.colorscheme

Do a quick check with ll /usr/share/qtermwidget5/color-schemes (ll is an ls alias for ls -l which shows permissions) and make sure the copied file has the same permissions as the rest of the files. If not, you can run sudo chmod 644 /usr/share/qtermwidget5/color-schemes/Kali-Dark.colorscheme.

Let's get out of xfce terminal and switch the launcher over to qterminal.

Go to the Properties for the terminal launcher and edit it to use qterminal instead.

Save it and open up a new terminal!

Don't worry, we'll set things right. Open up File | Preferences and change the font, color scheme, widget style, and other settings as shown below.

Odds and ends

At this point, everything should be looking pretty decent. There are a few more loose ends and they're all entirely optional. (To be fair though, this entire endeavor is entirely optional, so we might as well keep playing around with it.)

Qt5 Configuration Tool

Copy these files over real quick:

sudo cp ~/Downloads/kali-themes-kali-master/share/qt5ct/colors/Kali-Dark.conf /usr/share/qt5ct/colors/Kali-Dark.conf
sudo cp ~/Downloads/kali-themes-kali-master/share/qt5ct/qss/fusion-simple-scrollbar.qss /usr/share/qt5ct/qss/fusion-simple-scrollbar.qss

Again, you'll want to check the permissions and make sure they're correct. Assuming they're all good, let's open up the Qt5 Configuration Tool.

This will bring over the nice slim profile scrollbar as well as the fonts and theme configurations for certain contexts.

CPU Graph

Entirely unnecessary, but who doesn't like CPU graphs?

Kali uses this one in particular:

panel-plugins:xfce4-cpugraph-plugin:start [Xfce Docs]

We can just install it with apt.

sudo apt install xfce4-cpugraph-plugin

Right click on the panel and add a new CPU Graph to it.

It'll pop up way in the corner, hiding behind the clock. Go ahead and move it to where you want it, then bring up the properties for it. We just want to alter something from default to make it create a configuration file for it.

Head on over to your ~/.config/xfce4/panel directory and edit the cpugraph file. For me it was cpugraph-16.rc, but the specific number may be different for you. The little trick involved here is that the panel config files are loaded when the panel is loaded and saved again when the panel is closed. So editing the file while the panel is running will just be replaced with the extra hideous config we just created. So have an extra terminal open to stop the panel and restart it. Whether you load the file up in a gui editor, nano, vim, or whatever else, make your edits, shut down the panel, save the config, then start the panel up again.

Replace everything in the file with the following:

UpdateInterval=0
TimeScale=0
Size=128
Frame=0
Border=0
Bars=1
ColorMode=1
Foreground1=rgb(39,119,255)
Foreground2=rgb(0,255,224)
BarsColor=rgb(0,255,224)
PerCore=0
TrackedCore=0
InTerminal=1
StartupNotification=0

Close down the panel before saving with xfce4-panel -q, save the edited config file, and start the panel back up with xfce4-panel &. (The & will let you get back to a prompt and shut the terminal down without losing the panel. If the prompt doesn't show up immediately once the panel is running again, just hit return and it should pop up.)

Spicy root (optional)

This is completely optional (and entirely at your own risk), but you can also set the shell for root and enable a skull prompt as an additional visual indicator by copying over .zshrc to root's home and uncommenting the following line.

Again, it's up to you if you want to enable that. I thought it was nifty enough to share, and while I'm not one to gatekeep it should still be noted that missteps as root can come with consequences. If you aren't sure how to log in as root, or haven't ever messed with it before, don't feel bad about giving this a pass.

There are quite a few more configuration files for other contexts provided in the Kali theme files, and you can go as far down the rabbit hole as you'd like. This is about as far as I wanted to take it, but you're free to take a stroll through the theme files and pick out what you want from them. For instance, if you prefer to use the Xfce4 Terminal, there are Kali theme files for it. Or if you want the Kali themed syntax highlighting for Xed, you can copy over the gtksourceview files and set the theme in Xed.

There's a lot in there to scope out. Keep in mind you can also always compare to Kali itself to find what settings it uses. Enjoy!

When it comes to a lot of tech related stuff, there's divide between beginner level comprehension and practical implementation. There's simply something along the way that clicks into place in a way that makes so much sense that everything that came before the intuitive leap that enabled sudden comprehension seems to pale in comparison. All the rest of that junk you've spent days reading through didn't help like that one last thing did, did it?

That big intuitive leap, the main bit of insight, seems pithy enough to be able to relate to others but it is ultimately just icing on a cake of frustrated and desperate scrounging-for-information. Or perhaps a better analogy would be a door at the end of a labyrinth. For those who have successfully traversed the labyrinth, the path through seems perfectly reasonable.

Describing the Big Intuitive Leap is often no better than telling someone stuck in the labyrinth, "There's a door at the end. Just go through that."

As someone who has been stuck in the labyrinth more times than I'd care to admit, it's great knowing that there's a door at the end and all, but it doesn't do a whole lot to help me get there.

Keeping with this analogy though, there's still hope. Because even though most people just want to point to the door at the end as their helpful deed for the day, occasionally they drop other tidbits of information. "There's a door at the end just past a swampy pit filled with spikes and leeches." Now you know there's a pit of spikes and leeches, and that crossing that pit is necessary to reach the door. The more you scour the forum threads of oddly bad explanations, the more tidbits you can amalgamate into a rough map of how to get to the door.

Then once you find the door, you can experience the struggle of trying to recollect and explain your path through the labyrinth to someone else trapped inside.

One of the problems is that the labyrinth shifts. It's different for everyone because everyone is starting off from a different baseline of comprehension. Different backgrounds, different conceptualizations, and different fundamental mechanisms of learning.

Think of it as the Many-Labyrinth Interpretation. (And yes, I did enjoy this name so much that I made it the title of this post.)

The map for one person probably won't do the trick for someone else stuck in a different part of a similar, but ever-so-slightly different labyrinth. The swampy pit filled with spikes and leeches might still be there, but perhaps this time it's after the dancing skeleton that sings riddles instead of after the crow with a single white tail feather.

So even for those who put in monumental effort into their descriptions of escaping the labyrinth, the information may still not be the solution for someone else stuck inside.

"Don't let perfect be the enemy of good."

Determining the state of someone else's labyrinth and interposing your own map onto theirs in order to provide a best-possible-explanation can require a significant investment of time and energy. And that's assuming that communication barriers don't get in the way, which is rarely the case.

However, my map through my own labyrinth can still hopefully help someone else in theirs, even if they aren't the same. It all goes back to the tidbits of information. The labyrinths don't need to be a no-mans-land of information where people only want to describe the door at the end. Those discrete bits of description can still be helpful to someone else to point them in the right direction.

Helping someone doesn't necessarily entail solving all of their problems for them. Having been the person lost in the maze plenty of times, I certainly don't want people to hand me the solutions. Okay, maybe every once in a while it's a nice experience. But having a problem solved for me doesn't necessarily tell me how to solve a similar problem again in the future.

Most of the time, all it takes is to have my problems heard, and to be pointed in a direction. Even if that direction doesn't ultimately work out, I still value the direction because the things I learn along the way have intrinsic value. Not to mention that it helps to have that connection, and to not feel completely alone in an endeavor.

I believe that to be the case for most people seeking answers.