\n\n\nTL;DR Linux Kernel 6.11.10+/6.12/6.13 has AMDGPU regressions.
\nAdd
\nOption "SWCursor" "True"to/usr/share/X11/xorg.conf.d/10-amdgpu.confto resolve.Other's note
\namdgpu.dcdebugmask=0x10as a kernel parameter helps, didn't work for me.
Updating to Kernel 6.12, (after waiting for zfs-dkms to take a proverbial forever) I'd noticed that after opening an\napplication in AwesomeWM moving the mouse would bring my system to a halt.
\nI'd run into a regression on the kernel side of things with 6.11.10 which I'd not upgraded to. At the time, I just\nmigrated back to kernel 6.6.67 and moved on for a while.
\nZFS (and zfs-dkms) now support 6.13, so I was forced to revisit this after updating. A few folks recommended setting\namdgpu.dcdebugmask=0x10 as a kernel parameter, this didn't work.
https://www.reddit.com/r/archlinux/comments/1gzy0xd/amdgpu_regression_on_kernel_612_choppy/
\nDigging around, I'd noticed a post on the arch forums that suggested this may be an issue with the compositor. However,\nI am presently not using any with AwesomeWM.
\nhttps://bbs.archlinux.org/viewtopic.php?id=290868
\nAbout this time, I checked Plasma, and, interestingly enough, the issue was not present there. Maybe this can be due to\nmy lack of a compositor?
\nRegardless, I'd also observed I had a little bit of time until this issue cropped up, namely opening in Firefox. At this\ntime, I was able to observe in htop that xorg was pegging a core at 100% for a while. Thankfully, this let me find this\nobscure comment on the Manjaro forum.
\nhttps://forum.manjaro.org/t/high-cpu-use-by-xorg-with-kernel-6-12/174418/12
\nSo I modified my /etc/X11/xorg.conf.d/20-amdgpu.conf to the following:
❯ cat /etc/X11/xorg.conf.d/20-amdgpu.conf\n───────┬─────────────────────────────────────────────\n │ File: /etc/X11/xorg.conf.d/20-amdgpu.con\n │ f\n───────┼─────────────────────────────────────────────\n 1 │ Section "OutputClass"\n 2 │ Identifier "AMD"\n 3 │ MatchDriver "amdgpu"\n 4 │ Driver "amdgpu"\n 5 │ Option "VariableRefresh" "true"\n 6 │ Option "SWCursor" "true"\n 7 │ EndSection\n───────┴─────────────────────────────────────────────\nTrying it out, and, success!
\n❯ neofetch | lolcat\n -` disconsented@cadia\n .o+` ------------------\n `ooo/ OS: Arch Linux x86_64\n `+oooo: Host: B650 Pro RS\n `+oooooo: Kernel: 6.13.7-arch1-1\n -+oooooo+: Uptime: 1 hour, 15 mins\n `/:-:++oooo+: Packages: 1556 (pacman)\n `/++++/+++++++: Shell: fish 4.0.1\n `/++++++++++++++: Resolution: 3440x1440\n `/+++ooooooooooooo/` WM: awesome\n ./ooosssso++osssssso+` Theme: Breeze-Dark [GTK2/3]\n .oossssso-````/ossssss+` Icons: breeze [GTK2/3]\n -osssssso. :ssssssso. Terminal: alacritty\n :osssssss/ osssso+++. CPU: AMD Ryzen 9 7950X3D (32)\n /ossssssss/ +ssssooo/- GPU: AMD ATI Radeon RX 7900 XT\n `/ossssso+/:- -:/+osssso+- GPU: AMD ATI 11:00.0 Raphael\n `+sso+:-` `.-/+oso: Memory: 18258MiB / 63402MiB\n `++:. `-/+/\n .` `/\n\nAt this point, I am not entirely sure what's gone on. And, frankly I lack the skills and interest to dig further. I hope\nmy process and discovery is helpful to someone else!
\n", "permalink": "https://disconsented.com/blog/amdgpu-kernel-12-plus/", "slug": "amdgpu-kernel-12-plus", "ancestors": [ "_index.md" ], "title": "An AMDGPU regression in 6.12", "description": null, "updated": "2025-03-17", "date": "2025-03-17", "year": 2025, "month": 3, "day": 17, "taxonomies": { "year": [ "2025" ], "categories": [ "amd", "amdgpu", "linux" ] }, "authors": [], "extra": {}, "path": "/blog/amdgpu-kernel-12-plus/", "components": [ "blog", "amdgpu-kernel-12-plus" ], "summary": "\n\n", "toc": [], "word_count": 465, "reading_time": 3, "assets": [], "draft": false, "lang": "en", "lower": null, "higher": null, "translations": [], "backlinks": [] } ], "page_count": 1 }, { "name": "amdgpu", "slug": "amdgpu", "path": "/categories/amdgpu/", "permalink": "https://disconsented.com/categories/amdgpu/", "pages": [ { "relative_path": "blog/amdgpu-kernel-12-plus.md", "colocated_path": null, "content": "TL;DR Linux Kernel 6.11.10+/6.12/6.13 has AMDGPU regressions.
\nAdd
\nOption "SWCursor" "True"to/usr/share/X11/xorg.conf.d/10-amdgpu.confto resolve.Other's note
\namdgpu.dcdebugmask=0x10as a kernel parameter helps, didn't work for me.
\n\n\nTL;DR Linux Kernel 6.11.10+/6.12/6.13 has AMDGPU regressions.
\nAdd
\nOption "SWCursor" "True"to/usr/share/X11/xorg.conf.d/10-amdgpu.confto resolve.Other's note
\namdgpu.dcdebugmask=0x10as a kernel parameter helps, didn't work for me.
Updating to Kernel 6.12, (after waiting for zfs-dkms to take a proverbial forever) I'd noticed that after opening an\napplication in AwesomeWM moving the mouse would bring my system to a halt.
\nI'd run into a regression on the kernel side of things with 6.11.10 which I'd not upgraded to. At the time, I just\nmigrated back to kernel 6.6.67 and moved on for a while.
\nZFS (and zfs-dkms) now support 6.13, so I was forced to revisit this after updating. A few folks recommended setting\namdgpu.dcdebugmask=0x10 as a kernel parameter, this didn't work.
https://www.reddit.com/r/archlinux/comments/1gzy0xd/amdgpu_regression_on_kernel_612_choppy/
\nDigging around, I'd noticed a post on the arch forums that suggested this may be an issue with the compositor. However,\nI am presently not using any with AwesomeWM.
\nhttps://bbs.archlinux.org/viewtopic.php?id=290868
\nAbout this time, I checked Plasma, and, interestingly enough, the issue was not present there. Maybe this can be due to\nmy lack of a compositor?
\nRegardless, I'd also observed I had a little bit of time until this issue cropped up, namely opening in Firefox. At this\ntime, I was able to observe in htop that xorg was pegging a core at 100% for a while. Thankfully, this let me find this\nobscure comment on the Manjaro forum.
\nhttps://forum.manjaro.org/t/high-cpu-use-by-xorg-with-kernel-6-12/174418/12
\nSo I modified my /etc/X11/xorg.conf.d/20-amdgpu.conf to the following:
❯ cat /etc/X11/xorg.conf.d/20-amdgpu.conf\n───────┬─────────────────────────────────────────────\n │ File: /etc/X11/xorg.conf.d/20-amdgpu.con\n │ f\n───────┼─────────────────────────────────────────────\n 1 │ Section "OutputClass"\n 2 │ Identifier "AMD"\n 3 │ MatchDriver "amdgpu"\n 4 │ Driver "amdgpu"\n 5 │ Option "VariableRefresh" "true"\n 6 │ Option "SWCursor" "true"\n 7 │ EndSection\n───────┴─────────────────────────────────────────────\nTrying it out, and, success!
\n❯ neofetch | lolcat\n -` disconsented@cadia\n .o+` ------------------\n `ooo/ OS: Arch Linux x86_64\n `+oooo: Host: B650 Pro RS\n `+oooooo: Kernel: 6.13.7-arch1-1\n -+oooooo+: Uptime: 1 hour, 15 mins\n `/:-:++oooo+: Packages: 1556 (pacman)\n `/++++/+++++++: Shell: fish 4.0.1\n `/++++++++++++++: Resolution: 3440x1440\n `/+++ooooooooooooo/` WM: awesome\n ./ooosssso++osssssso+` Theme: Breeze-Dark [GTK2/3]\n .oossssso-````/ossssss+` Icons: breeze [GTK2/3]\n -osssssso. :ssssssso. Terminal: alacritty\n :osssssss/ osssso+++. CPU: AMD Ryzen 9 7950X3D (32)\n /ossssssss/ +ssssooo/- GPU: AMD ATI Radeon RX 7900 XT\n `/ossssso+/:- -:/+osssso+- GPU: AMD ATI 11:00.0 Raphael\n `+sso+:-` `.-/+oso: Memory: 18258MiB / 63402MiB\n `++:. `-/+/\n .` `/\n\nAt this point, I am not entirely sure what's gone on. And, frankly I lack the skills and interest to dig further. I hope\nmy process and discovery is helpful to someone else!
\n", "permalink": "https://disconsented.com/blog/amdgpu-kernel-12-plus/", "slug": "amdgpu-kernel-12-plus", "ancestors": [ "_index.md" ], "title": "An AMDGPU regression in 6.12", "description": null, "updated": "2025-03-17", "date": "2025-03-17", "year": 2025, "month": 3, "day": 17, "taxonomies": { "year": [ "2025" ], "categories": [ "amd", "amdgpu", "linux" ] }, "authors": [], "extra": {}, "path": "/blog/amdgpu-kernel-12-plus/", "components": [ "blog", "amdgpu-kernel-12-plus" ], "summary": "\n\n", "toc": [], "word_count": 465, "reading_time": 3, "assets": [], "draft": false, "lang": "en", "lower": null, "higher": null, "translations": [], "backlinks": [] } ], "page_count": 1 }, { "name": "linux", "slug": "linux", "path": "/categories/linux/", "permalink": "https://disconsented.com/categories/linux/", "pages": [ { "relative_path": "blog/amdgpu-kernel-12-plus.md", "colocated_path": null, "content": "TL;DR Linux Kernel 6.11.10+/6.12/6.13 has AMDGPU regressions.
\nAdd
\nOption "SWCursor" "True"to/usr/share/X11/xorg.conf.d/10-amdgpu.confto resolve.Other's note
\namdgpu.dcdebugmask=0x10as a kernel parameter helps, didn't work for me.
\n\n\nTL;DR Linux Kernel 6.11.10+/6.12/6.13 has AMDGPU regressions.
\nAdd
\nOption "SWCursor" "True"to/usr/share/X11/xorg.conf.d/10-amdgpu.confto resolve.Other's note
\namdgpu.dcdebugmask=0x10as a kernel parameter helps, didn't work for me.
Updating to Kernel 6.12, (after waiting for zfs-dkms to take a proverbial forever) I'd noticed that after opening an\napplication in AwesomeWM moving the mouse would bring my system to a halt.
\nI'd run into a regression on the kernel side of things with 6.11.10 which I'd not upgraded to. At the time, I just\nmigrated back to kernel 6.6.67 and moved on for a while.
\nZFS (and zfs-dkms) now support 6.13, so I was forced to revisit this after updating. A few folks recommended setting\namdgpu.dcdebugmask=0x10 as a kernel parameter, this didn't work.
https://www.reddit.com/r/archlinux/comments/1gzy0xd/amdgpu_regression_on_kernel_612_choppy/
\nDigging around, I'd noticed a post on the arch forums that suggested this may be an issue with the compositor. However,\nI am presently not using any with AwesomeWM.
\nhttps://bbs.archlinux.org/viewtopic.php?id=290868
\nAbout this time, I checked Plasma, and, interestingly enough, the issue was not present there. Maybe this can be due to\nmy lack of a compositor?
\nRegardless, I'd also observed I had a little bit of time until this issue cropped up, namely opening in Firefox. At this\ntime, I was able to observe in htop that xorg was pegging a core at 100% for a while. Thankfully, this let me find this\nobscure comment on the Manjaro forum.
\nhttps://forum.manjaro.org/t/high-cpu-use-by-xorg-with-kernel-6-12/174418/12
\nSo I modified my /etc/X11/xorg.conf.d/20-amdgpu.conf to the following:
❯ cat /etc/X11/xorg.conf.d/20-amdgpu.conf\n───────┬─────────────────────────────────────────────\n │ File: /etc/X11/xorg.conf.d/20-amdgpu.con\n │ f\n───────┼─────────────────────────────────────────────\n 1 │ Section "OutputClass"\n 2 │ Identifier "AMD"\n 3 │ MatchDriver "amdgpu"\n 4 │ Driver "amdgpu"\n 5 │ Option "VariableRefresh" "true"\n 6 │ Option "SWCursor" "true"\n 7 │ EndSection\n───────┴─────────────────────────────────────────────\nTrying it out, and, success!
\n❯ neofetch | lolcat\n -` disconsented@cadia\n .o+` ------------------\n `ooo/ OS: Arch Linux x86_64\n `+oooo: Host: B650 Pro RS\n `+oooooo: Kernel: 6.13.7-arch1-1\n -+oooooo+: Uptime: 1 hour, 15 mins\n `/:-:++oooo+: Packages: 1556 (pacman)\n `/++++/+++++++: Shell: fish 4.0.1\n `/++++++++++++++: Resolution: 3440x1440\n `/+++ooooooooooooo/` WM: awesome\n ./ooosssso++osssssso+` Theme: Breeze-Dark [GTK2/3]\n .oossssso-````/ossssss+` Icons: breeze [GTK2/3]\n -osssssso. :ssssssso. Terminal: alacritty\n :osssssss/ osssso+++. CPU: AMD Ryzen 9 7950X3D (32)\n /ossssssss/ +ssssooo/- GPU: AMD ATI Radeon RX 7900 XT\n `/ossssso+/:- -:/+osssso+- GPU: AMD ATI 11:00.0 Raphael\n `+sso+:-` `.-/+oso: Memory: 18258MiB / 63402MiB\n `++:. `-/+/\n .` `/\n\nAt this point, I am not entirely sure what's gone on. And, frankly I lack the skills and interest to dig further. I hope\nmy process and discovery is helpful to someone else!
\n", "permalink": "https://disconsented.com/blog/amdgpu-kernel-12-plus/", "slug": "amdgpu-kernel-12-plus", "ancestors": [ "_index.md" ], "title": "An AMDGPU regression in 6.12", "description": null, "updated": "2025-03-17", "date": "2025-03-17", "year": 2025, "month": 3, "day": 17, "taxonomies": { "year": [ "2025" ], "categories": [ "amd", "amdgpu", "linux" ] }, "authors": [], "extra": {}, "path": "/blog/amdgpu-kernel-12-plus/", "components": [ "blog", "amdgpu-kernel-12-plus" ], "summary": "\n\n", "toc": [], "word_count": 465, "reading_time": 3, "assets": [], "draft": false, "lang": "en", "lower": null, "higher": null, "translations": [], "backlinks": [] } ], "page_count": 1 }, { "name": "Networking", "slug": "networking", "path": "/categories/networking/", "permalink": "https://disconsented.com/categories/networking/", "pages": [ { "relative_path": "blog/basics-of-networking.md", "colocated_path": null, "content": "TL;DR Linux Kernel 6.11.10+/6.12/6.13 has AMDGPU regressions.
\nAdd
\nOption "SWCursor" "True"to/usr/share/X11/xorg.conf.d/10-amdgpu.confto resolve.Other's note
\namdgpu.dcdebugmask=0x10as a kernel parameter helps, didn't work for me.
Frequently across varying game hosting communities I see folks trying to start hosting servers for their friends but typically running into the same sets of roadblocks, blindly following poorly written guides & videos.
\nInstead of getting grumpy, trying to explain the process for the Nth time, I've decided to (shockingly) write out a guide to hopefully help folks, help themselves.
\n\nGiven my years of experience inside varying Minecraft Server communities (shout out to Syscraft), running my Infrastructure as a Service (PixelPond.io) & my experience in Residential Access Networks, I figured it was time to impart a bit of wisdom.
\nThe goal of this guide is to explain enough for folks to get started, with a focus on teaching a set of tools (both software and logical) to diagnose their home networks.
\nWhat this guide, isn't, is a complete guide to port forwarding with X ISP or Y CPE (typically a router). Due diligence on the part of the reader is expected, this is fork feeding, not spoon-feeding.
\nN.A.T. or Network Address Translation (like most acronyms) is quite a literally named. In a nutshell, it's the idea that a network device can take a request and then translate it to another address.
\nThe way it works is by modifying the Source I.P. and Destination I.P. segments of the packet and forwarding it along the network.
\nTypically, the C.P.E. figure out how & where to translate the incoming address by looking at the Destination. It will then modify that to point towards another device and forward that along.
\nSay you get a packet that looks like:
\n| Source Address | Source Port | Destination Address | Destination Port |
|---|---|---|---|
| 123.123.123.123 | 25565 | 10.0.0.1 | 25565 |
Your CPE may then have a NAT table that looks like:
\n| Source Address | Source Port | Destination Address | Destination Port |
|---|---|---|---|
| 0.0.0.0 | 25565 | 192.168.1.20 | 25565 |
| 10.0.0.1 | 80 | 192.168.1.20 | 8080 |
In this case, it has two rules:
\nFrom there, it can modify the packet to:
\n| Source Address | Source Port | Destination Address | Destination Port |
|---|---|---|---|
| 10.10.10.10 | 25565 | 192.168.1.20 | 25565 |
So, it's rewritten the Destination Address and forwarded the packet on its mary way. It was able to do so because it had been told what to do via the NAT table.
\nIn practice, this is the mechanism that lets people access services behind a C.P.E. (Router) in IPv4 networks. IPv6 doesn't use the concept of NAT because each device has its own (public) address.
\nHowever, this mechanism doesn't always work for varying reasons. We'll touch on the two most common ones here, “Hairpin N.A.T.” and C.G.N.A.T.
\nHairpin NAT is the idea of communicating to a local host behind the same NAT device (CPE). E.g., connecting to a local server by using the WAN address of the CPE.
\nWhy did I include this? Well, I've noticed that folks who are new to dealing with home networks tend to think that using your CPE's WAN address is a good way to test your port forward.
\nIn reality, attempting to test this way achieves nothing beyond verifying that your Hairpin NAT works. It's convenient in some cases, but ultimately a red herring.
\nCGNAT, or Carrier Grade NAT, is a way for ISPs to save money on paying for an IP address for each customer. It works much the same way as regular NAT, but instead of it operating on your CPE, it operates on a network appliance somewhere in your provider's network. Unfournatley, you have no direct influence over how it operates. Consequently, you cannot port forward when your ISP is using CGNAT.
\nIt is trivial to establish if you're stuck behind CGNAT, you'll see that your CPEs WAN address is different to what services will report your WAN address as.
\nI.e., say your CPE has an WAN address of 10.0.0.25 & a service like icanhazip says your address is 123.123.123.123 you're stuck behind CGNAT.
Fret not, you can work around this via “Tunneling” although, we won't dive into this topic here.
\nRemember that weird address from the NAT table before, 0.0.0.0? It's a special address in many special rules depending on the context, but here it has one relevant meaning. Anything, why do we care? Because it's the only address we should ever bind a server to.
Have you ever noticed how some servers let you specify an address?
\n\n\nE.g.
\nserver-ip=
When you specify a value, you're telling the application to only listen to that address. Typically, you'll want this when you have a machine with multiple addresses and several services with the same ports. For example: 10.0.0.2:25565 & 10.0.0.3:25565.
Previously, we discussed how NAT works and its role in connecting your server to the internet. As every device on the network needs an address to be reachable, and there are not enough IP(v4) addresses for each machine to have a unique one. The IETF set aside various address spaces for private use.
\nThis overlap, combined with NAT is largely how the problem of IPv4 address exhaustion was tackled. It is important to understand how this works for understanding how your traffic is directed.
\nEssentially, the globally unique address by which you can be reached. This will be the address of your CPE for IPv4 networks and how your network can be found on the internet.
\nThe Internet Protocol (IP) is essentially the layer that lets you route traffic between the interconnected networks of the internet, largely in v4 and v6 layers. A brief description, but it covers the broad strokes.
\nProgrammatically, IPv4 and IPv6 are made up of 32 bits and 128 bits, respectively. The adoption of IPv6 is largely driven by the IPv4 address exhaustion problem, consequently, this is why NAT has seen widespread adoption. Every bit you add, doubles the range of numbers that you can represent. IPv4 can represent roughly 4 million addresses (with special ranges not for general use), IPv6 can represent 340 undecillion addresses. These are enough addresses that practically every device on the internet can have its own unique address, in residential settings, instead of a single IPv4 address you'll typically have an IPv6 prefix.
\nISPs have been historically slow to adopt IPv6 through a lack of demand and the equipment cost behind it. However, support for IPv6 has grown to the point where it is not unusual to see it being offered to residential customers.
\nFurthermore, because of the support for IPv6 in major services, ISPs are supporting it as a way of reducing load on their CGNAT equipment, consequently saving significant cost on equipment.
\nNetwork interfaces don't have an IP address directly associated with them, instead, each interface has its own unique hardware address that needs to be mapped against an IP address to be routable. This is done with the Address Resolution Protocol, network equipment will keep a collection of these mappings to know how to route traffic to interfaces across the network.
\nJust to raise awareness of these tools, TCP Dump & Wireshark are packet capture tools that can be used to capture, analyse network traffic, consequently they're excellent tools for diagnosing issues.
\nHowever, these tools are complex enough that I won't be able to do them justice.
\nNot a specific tool but rather a concept, most firewall solutions (whether they're on a CPE or a server) have an option of logging events. This is a great step for sanity checking whether traffic is hitting a particular device, as an example.
\nTypically, this is one of the following :\n\nAddress port pair is already in use, to resolve this, pick another unique combination or stop whatever is using that one.\nUsing a port from the reserved range, user space applications must use a port >1024.\nNo adapters with the specified address, for multiple routable addresses, assign them to the interface, otherwise bind to Quad0.Frequently across varying game hosting communities I see folks trying to start hosting servers for their friends but typically running into the same sets of roadblocks, blindly following poorly written guides & videos.
\nInstead of getting grumpy, trying to explain the process for the Nth time, I've decided to (shockingly) write out a guide to hopefully help folks, help themselves.
\n", "toc": [ { "level": 2, "id": "preface", "permalink": "https://disconsented.com/blog/basics-of-networking/#preface", "title": "Preface", "children": [] }, { "level": 2, "id": "what-is-n-a-t", "permalink": "https://disconsented.com/blog/basics-of-networking/#what-is-n-a-t", "title": "What is N.A.T?", "children": [] }, { "level": 2, "id": "hairpin-nat-alternatively-why-you-don-t-test-from-your-port-forward-from-your-lan", "permalink": "https://disconsented.com/blog/basics-of-networking/#hairpin-nat-alternatively-why-you-don-t-test-from-your-port-forward-from-your-lan", "title": "Hairpin NAT, alternatively, why you don't test from your port forward from your LAN", "children": [] }, { "level": 2, "id": "cgnat-the-other-big-scary-nat", "permalink": "https://disconsented.com/blog/basics-of-networking/#cgnat-the-other-big-scary-nat", "title": "CGNAT, the other big scary NAT", "children": [] }, { "level": 2, "id": "what-is-quad-0", "permalink": "https://disconsented.com/blog/basics-of-networking/#what-is-quad-0", "title": "What is Quad 0", "children": [] }, { "level": 2, "id": "address-binding", "permalink": "https://disconsented.com/blog/basics-of-networking/#address-binding", "title": "Address Binding", "children": [] }, { "level": 2, "id": "private-lan-address", "permalink": "https://disconsented.com/blog/basics-of-networking/#private-lan-address", "title": "Private/LAN Address", "children": [] }, { "level": 2, "id": "public-wan-address", "permalink": "https://disconsented.com/blog/basics-of-networking/#public-wan-address", "title": "Public/WAN Address", "children": [] }, { "level": 2, "id": "ipv4-ipv6", "permalink": "https://disconsented.com/blog/basics-of-networking/#ipv4-ipv6", "title": "IPv4 & IPv6", "children": [] }, { "level": 2, "id": "mac-binding-i-e-how-does-the-router-know-where-to-direct-traffic", "permalink": "https://disconsented.com/blog/basics-of-networking/#mac-binding-i-e-how-does-the-router-know-where-to-direct-traffic", "title": "MAC Binding (I.E. how does the router know where to direct traffic)", "children": [] }, { "level": 2, "id": "tcp-dump-wireshark", "permalink": "https://disconsented.com/blog/basics-of-networking/#tcp-dump-wireshark", "title": "TCP Dump & Wireshark", "children": [] }, { "level": 2, "id": "firewall-logs", "permalink": "https://disconsented.com/blog/basics-of-networking/#firewall-logs", "title": "Firewall Logs", "children": [ { "level": 3, "id": "addendum-1-fail-to-bind-address-already-in-use", "permalink": "https://disconsented.com/blog/basics-of-networking/#addendum-1-fail-to-bind-address-already-in-use", "title": "Addendum 1 — Fail to Bind (Address already in use)", "children": [] } ] } ], "word_count": 1389, "reading_time": 7, "assets": [], "draft": false, "lang": "en", "lower": null, "higher": null, "translations": [], "backlinks": [] } ], "page_count": 1 } ] }