Author: viktor

  • Gaming on Linux and fixing crashes

    Gaming on Linux and fixing crashes

    I like many others switched to Linux for gaming. There is only so much co-pilot nonsense and quality issues one can take. So after reading up and checking out what gaming or semi mixed use distributions were out there I started my journey.

    Where to begin?

    I started out with installing Bazzite on my machine. The install process was pain-free and I was gaming within the hour. Using steam and proton a great deal of windows games work well. However certain AAA titles such as Call of duty and Battlefield requires kernel-level anti-cheat. This is generally not compatible with any proton/wine/Linux machine. And in Battlefields case they actually actively block anything but Windows.

    Where I ended up:

    I used Bazzite for around 2 months. However since i do more than gaming on my machine, it got frustrating with an immutable distribution. I moved on to using CachyOS instead, the experience is more or less the same for gaming. And now i wont have to fight to install or compile software not included in the default repositories.

    Games that worked:

    ARC Raiders
    The Finals
    Pretty much all Valve games
    Delta Force (with some trickery, thanks anti-cheat)
    Split Fiction
    Arma Reforger

    and by worked I mean once installed it was the exact same experience as on Windows.

    Issues and crashes:

    Delta Force
    the game worked fine with proton in steam, however the anti-cheat caused the game to not launch. Delta Force uses Easy Anti-Cheat which is actually Linux compatible. However it appears the developers had actively denied Linux or configured it in a way where Linux compatibility was impossible. Luckily ProtonDB has many clever users who found solutions. It turned out you could replace the version of Easy Anti-Cheat from delta force with another from a game with Linux compatible configuration. Replacing the anti-cheat files with files from Strinova(free-to-play) fixed the issue. As of time of writing I’m unsure if this fix still works. I haven’t played the game in a while.

    ARC Raiders

    Excellent Linux support in general, but easy anti-cheat can cause some issues if you have a slightly older CPU. It uses an older and mostly disabled feature in modern CPUs to detect cheats. Most CPUs emulate the feature in software and it causes no issues at all. I however had the luck of having constant crashes after 30-60minutes of play time.

    I used the powerful terminal features to narrow down the issue. Checking with “journalctl -b -1 -k” which checks all logs from your last boot where you had the crash. I found a lot of errors regardning UMIP. If you’re having crashes and want to check quickly if you have the same issue, this one-liner will tell you “journalctl -b -1 -k | grep -Ei “umip|vsyscall|exception”

    Fix:
    the fix is scary at first but quite simple technically speaking.
    you have to disable UMIP in your boot parameters. This is done differently depending on your distribution of linux. Generally speaking you can edit your configuration in bootloader and add:
    vsyscall=none umip=off $vt_handoff

  • Fixing myself some redundancy

    Fixing myself some redundancy

    I’ve never been a network technician and with any luck I never will be either. However a certain opportunity presented itself to me lately. I’ve recently upgraded my switches at home to managed switches which enables some proper shenanigans.

    I’ve been lucky enough to buy a terraced house with two separate internet providers wired in. First we have a cable based ISP which provides 100mbit download and 10mbit upload. This is far too slow for my liking but it has a distinct advantage. It’s included in my fee to the housing society. The second provider is a standard cat6 connection which provides 1000mbit in both directions. Naturally since I’ve moved in this is what i have been using, the downside is that it does cost me 30euros/month.

    So how does this relate to the managed switches? Well you see.. as is often the case with cable(coax) provided internet, it’s never located conveniently close to your servers. It is however often located conveniently close to your TV. Where as my cat6 provider has its jack located near the front door. I’ve already pulled an Ethernet cable to my TV box from my switch located elsewhere. So the Ethernet run to the inconvenient coax provider was already sort of there. Pulling an extra Ethernet from the TV back to my router was both inconvenient and politically sensitive in my household. The only viable solution was to call upon the power of friendship, magic and VLANs.

    The first step was to create a new VLAN i my switches. I’m using rather cheap somewhat crappy zyxel managed switches. They use a somewhat different terminology to big players such as Cisco and Ubiquiti. However the end result is the same.

    after creating the vlan on both of my switches i trunked the vlan on the port connecting the switches. In Zyxel terms this is called “tagging egress member” in my case for port 3 in the switch:

    in the above image the coax internet is running on VLAN ID 3.
    Since my coax internet provider only provides a basic DOCSIS cable modem, which has no clue what a VLAN is. The configuration for that port was set to untagged and the PVID of the port was set to 3

    This means the cable modem only ever knows about vlan 3 and it has no clue about anything else.
    in the other switch located next to my Ubiquiti router i configured a port in the exact same way. No need to get fancy unless we have to, right?

    In the router, i plugged in a cable to my new fancy VLAN 3 port, and just added a “WAN”, told it which port to use as new WAN and I was off to the races.

    The end result:

    So now, whenever i lose 2 ping packets on my primary connection it will automatically fail-over to the coax provider.