ElDapper

make things as simple as possible

  • pf switcher: a pf interface selector made with bsddialog

    External network access for Bastille jails requires configuring a table and NAT rule in pf for the bastille0 loopback interface, as explained on the BastilleBSD getting started page: https://bastillebsd.org/getting-started/

    ext_if="vtnet0"

set block-policy return
scrub in on $ext_if all fragment reassemble
set skip on lo

table <jails> persist
nat on $ext_if from <jails> to any -> ($ext_if:0)
rdr-anchor "rdr/*"

    I use a bastille jail to run unbound as an ad blocker. There is a convenient template on the Bastille Gitlab page to bootstrap Unbound + adblock https://gitlab.com/bastillebsd-templates/unbound-adblock.

    Given that I run this jail on my laptop, I needed a straightforward simple method to adjust the interface in the /etc/pf.conf file, to easily switch between Ethernet and Wi-Fi without manual intervention.

    For this purpose, I wrote a simple, yet effective script for seamless pf configuration switching:

    cat /home/mcapella/bin/pf_switcher.sh

    #!/bin/sh

# Get a list of available network interfaces
available_interfaces=$(ifconfig -l)

# Check if any interfaces are available
if [ -z "$available_interfaces" ]; then
  echo "No network interfaces found."
  exit 1
fi

# Display available interfaces
echo "Available network interfaces:"
echo "$available_interfaces"

# Prompt the user to choose an interface
read -p "Enter the new interface name: " new_ext_if

# Update the configuration file
if [ -n "$new_ext_if" ]; then
  doas sed -i '' "s/^ext_if=.*/ext_if="$new_ext_if"/" "/etc/pf.conf"
  echo "ext_if updated to $new_ext_if"
else
  echo "No interface name provided. Exiting."
  exit 1
fi

echo "Restarting pf"
doas pfctl -f /etc/pf.conf

    I shared this script with Vermaden during a conversation about one of his excellent tutorials, and he kindly responded with a refined version designed to offer a user-friendly interface for selecting and switching network interfaces within the pf configuration file. It’s a significant enhancement over the original script, incorporating a user interface using bsddialog for interface selection.

    Afterward, I customized his example to better suit my preferences:

    #! /bin/sh

: ${TERMINAL_STDOUT_PASSTHRU:=3}
: ${TERMINAL_STDERR_PASSTHRU:=4}
: ${DIALOG_TERMINAL_PASSTHRU_FD:=${TERMINAL_STDOUT_PASSTHRU:-3}}
eval exec ${TERMINAL_STDOUT_PASSTHRU}>&1
eval exec ${TERMINAL_STDERR_PASSTHRU}>&2

EXCLUDED='(vm-public|bridge0|bastille0)'

MENU_LIST=$( ifconfig -l ether | tr ' ' 'n' | grep -E -v "${EXCLUDED}" | awk '{print $NF, "Interface" }'  )

MENU_CHOICE=$( bsddialog --clear 
          --title "pf interface switcher" 
          --backtitle "pf Interface Switcher" 
          --hline "<<-->>" 
          --menu "Select active interface" 
          0 40 0 
          ${MENU_LIST} 
          2>&1 >&${DIALOG_TERMINAL_PASSTHRU_FD}
             )

RETVAL=${?}

echo
echo "RETVAL:${RETVAL}"
echo "MENU_CHOICE:${MENU_CHOICE}"

# UPDATE CONFIGURATION FILE
if [ -n "${MENU_CHOICE}" ]
then
  doas sed -i '' "s/^ext_if=.*/ext_if="${MENU_CHOICE}"/" "/etc/pf.conf"
  echo "ext_if updated to ${MENU_CHOICE}"
else
  echo "No interface name provided. Exiting."
  exit 1
fi

echo "Restarting pf"
doas pfctl -f /etc/pf.conf

    Now It looks like this:

    This script provides a convenient way to switch network interfaces in my pf configuration, making it easier to switch between different interfaces like Ethernet and Wi-Fi.

    Thank you Vermaden!

    , , , , , , ,

  • WireGuard VNET jail

    Creating the Jail:

    I created the jail using Bastille like this:

    bastille create -V wirevnet 14.0-RELEASE 0.0.0.0 bge1

    Initially, I assigned the IP address “0.0.0.0” to the jail. Then, using

    bastille cmd wirevnet ifconfig,

    I retrieved the Ethernet address and utilized it to create a static reservation on the router.

    Configuring Hostname and SSH:

    Next, I assign it a hostname and enable SSH. Then, I create my user account [eldapper] using ‘adduser’ and use ‘ssh-copy-id’ to add the public key. For security remove the password using ‘pw mod user [eldapper] -w no’. Finally I edit the sshd_config and harden it a bit.

    # cat /etc/ssh/sshd_config

    PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yes

    Configuration:

    # cat /etc/rc.conf

    ifconfig_e0b_bastille5_name="vnet0"
#ifconfig_vnet0="SYNCDHCP "
ifconfig_vnet0="inet 192.168.1.254/24 up"
defaultrouter="192.168.1.254"
hostname="wirevnet.eldapper.com"
gateway_enable="YES"
# SSH
sshd_enable="YES"

## wireguard server
wireguard_interfaces="wg0"
wireguard_enable="YES"

## wireguard-ui
wireguard_ui_enable="YES"
wgui_enable="YES"

## pf firewall
pf_enable="YES"
pf_rules="/etc/pf.conf"

    Firewall

    On the router create a redirect rule for the Wireguard Listen Port: 51820 to the jail’s IP: 192.168.1.254.

    Kernel Module

    Wireguard kernel module: On the host ensure that the if_wg kernel module is loaded automatically during system boot.

    kld_list="if_wg"

    Then allow the module on the jail: for the loaded module to pass through the jail you need to edit the jail.conf by adding allow.sysvipc;

    # cat /usr/local/bastille/jails/wirevnet/jail.conf

    wirevnet {
  devfs_ruleset = 13;
  enforce_statfs = 2;
  exec.clean;
  exec.consolelog = /var/log/bastille/wirevnet_console.log;
  exec.start = '/bin/sh /etc/rc';
  exec.stop = '/bin/sh /etc/rc.shutdown';
  host.hostname = wirevnet;
  mount.devfs;
  mount.fstab = /usr/local/bastille/jails/wirevnet/fstab;
  path = /usr/local/bastille/jails/wirevnet/root;
  securelevel = 2;
  osrelease = 14.0-RELEASE;

# Allow loading kernel modules
  allow.sysvipc;

  vnet;
  vnet.interface = e0b_bastille5;
  exec.prestart += "jib addm bastille5 bge1";
  exec.prestart += "ifconfig e0a_bastille5 description \"vnet host interface for Bastille jail wirevnet\"";
  exec.poststop += "jib destroy bastille5";

    Gateway & NAT

    Packet forwarding and NAT must be enabled on the FreeBSD server if we wish to route and forward our VPN client packets. Modifying /etc/rc.conf enables packet forwarding

    gateway_enable="YES

    The gateway_enable="YES" setting in FreeBSD’s /etc/rc.conf file enables the system to act as a network gateway, allowing it to forward packets between interfaces. If your host system is configured as a gateway and you want your jail to also act as a gateway, you should enable gateway_enable="YES" in the jail’s /etc/rc.conf as well.

    Enabling gateway_enable="YES" in the jail’s /etc/rc.conf is necessary if you want the jail to perform tasks like packet forwarding, NAT (Network Address Translation), or routing between different network interfaces within the jail.

    wireguard, wireguard-ui, wgui daemons

    Install wireguard tools

    ➡️ Wireguardtools-1.0.20210914_3 Fast, modern and secure VPN Tunnel

    pkg install wireguard-tools

    Enable wireguard
    ## wireguard server
    wireguard_interfaces="wg0"
    wireguard_enable="YES"

    Download wireguard-ui

    https://github.com/ngoduykhanh/wireguard-ui

    Releases: https://github.com/ngoduykhanh/wireguard-ui/releases

    ➡️ Install wireguard-ui
    mkdir -p /usr/local/etc/wireguard-ui/

wget -c https://github.com/ngoduykhanh/wireguard-ui/releases/download/v0.6.2/wireguard-ui-v0.6.2-freebsd-amd64.tar.gz -O - | tar -xz -C /usr/local/etc/wireguard-ui/
    # tree -a /usr/local/etc/wireguard-ui/

    ├── db
    │   ├── clients
    │   ├── server
    │   │   ├── global_settings.json
    │   │   ├── hashes.json
    │   │   ├── interfaces.json
    │   │   └── keypair.json
    │   ├── users
    │   │   └── admin.json
    │   └── wake_on_lan_hosts
    ├── env
    └── wireguard-ui
    Create a wireguard-ui Startup Script

    # cat /usr/local/etc/rc.d/wireguard-ui

    #!/bin/sh
#
# PROVIDE: wireguard_ui
# REQUIRE: DAEMON
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf to enable wireguard_ui:
#
# wireguard_ui_enable="YES"
#
. /etc/rc.subr
name="wireguard_ui"
rcvar=wireguard_ui_enable
procname="/usr/local/etc/wireguard-ui/wireguard-ui"
pidfile="/var/run/wireguard_ui.pid"
wireguard_ui_chdir="/usr/local/etc/wireguard-ui"
wireguard_ui_env_file="/usr/local/etc/wireguard-ui/env"
command="/usr/sbin/daemon"
command_args=" -s notice -p ${pidfile} -f ${procname} ${wireguard_ui_env_file}"
stop_postcmd="wireguard_ui_poststop"
wireguard_ui_poststop()
{
    rm -f $pidfile
}
load_rc_config ${name}
: ${wireguard_ui_enable="NO"}
: ${wireguard_ui_pidfile="/var/run/${name}.pid"}
run_rc_command "$1"

    chmod +x /usr/local/etc/rc.d/wireguard-ui

    add to /etc/rc.conf: wireguard_ui_enable="YES"

    Create Environment Variables file and configure it
    #!/usr/local/bin/bash
WGUI_USERNAME="admin"
WGUI_PASSWORD="1password"
SMTP_HOSTNAME="smtp.somemailserver.com"
SMTP_PORT="587"
SMTP_USERNAME="eldapper@somemailserver.com"
SMTP_PASSWORD="1234"
SMTP_NO_TLS_CHECK="true"
SMTP_AUTH_TYPE="LOGIN"
EMAIL_FROM_NAME="WireGuard-UI"
EMAIL_FROM_ADDRESS="eldapper@somemailserver.com"
WGUI_DNS="192.168.1.2,192.168.1.3"
WGUI_CONFIG_FILE_PATH="/usr/local/etc/wireguard/wg0.conf"
WGUI_SERVER_INTERFACE_ADDRESSES="10.10.100.0/24"

    wireguard restart daemon

    After installing and enabling the service you can reach the ui at port 5000

    http://192.168.1.254:5000

    In WireGuard, adding new clients requires restarting the server to apply the changes. However, WireGuard-UI in FreeBSD lacks this functionality. To address this, I’ve wrote a simple daemon to monitor changes in the ‘/usr/local/etc/wireguard/wg0.conf’ configuration file. For the script to work we need inotifywait first:

    pkg install inotify-tools

    # cat /usr/local/etc/rc.d/wgui

    #!/bin/sh
#
# PROVIDE: wgui
# REQUIRE: DAEMON
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf to enable wgui:
#
# wgui_enable="YES"
#

. /etc/rc.subr

name="wgui"
rcvar=wgui_enable
procname="/usr/local/etc/wgui/wgui"
pidfile="/var/run/wgui.pid"
#wgui_chdir="/usr/local/opt/wgui/"
command="/usr/sbin/daemon"
command_args="-P ${pidfile} ${procname}"

stop_cmd="${name}_stop"
stop_postcmd="${name}_poststop"


wgui_stop()
{
        if [ -f $pidfile ]; then
                echo "Stopping wgui."
                kill $(cat $pidfile)
                echo "Stopped wgui."
        else
                echo "wgui is not running."
                exit 0
        fi
}


wgui_poststop()
{
        rm -f  $pidfile
}

load_rc_config ${name}

: ${wgui_enable="NO"}
: ${wgui_pidfile="/var/run/${name}.pid"}

run_rc_command "$1"

    # cat /usr/local/etc/wgui/wgui

    #!/bin/sh
PATH="$PATH:/usr/local/bin"
while inotifywait -e modify -e create  /usr/local/etc/wireguard/; do
  wg-quick down wg0
  wg-quick up wg0
done

    After adding the script and making it executable chmod +x /usr/local/etc/wgui/wgui we enable it:

    wgui_enable="YES"

    pf firewall

    On the jail I configured pf like this:

    # cat /etc/pf.conf

    wireguard_clients="10.10.100.0/24"
wanint="vnet0"
wg_ports="{51821}"
set skip on lo0
nat on $wanint inet from $wireguard_clients to any -> $wanint
pass in on $wanint proto udp from any to $wanint port $wg_ports
pass in on $wanint proto tcp from any to $wanint port 22 keep state
pass out quick
pass in on wg0 from any to any

    ,
    , ,

  • Installing FreeBSD 14.0 on a 2013 Mac Pro

    Installer

    Downloaded FreeBSD-14.0-RELEASE-amd64-memstick.img burned it on a USB thumb drive. Edited the /boot/loader.conf by adding the following line:

    hw.pci.enable_pcie_hp="0" to disable PCI-express HotPlug because it would not boot otherwise and the console would spit out pcib8: Power Fault Detected in a loop. While researching how to overcome the boot fault I discovered this page: https://anschwa.com/blog/2022/01/03/installing-freebsd-on-2013-macpro.html where someone else had done what I was trying to accomplish. I followed the instructions but then I realized that the partition created by Adam in that blog was UFS and not ZFS as I wanted, a dual boot macOS Monterey + FreeBSD 14.0 in a ZFS partition. I’m not sure this is a good idea but I did it anyway.

    Resizing macOS

    The Mac Pro has a 500GB HD. I resized my macOS partition by adding an additional 2 partitions. 125GB for the MacOS partition, 371GB “untitled 2” for my FreeBSD install and 4.11 GB partition “untitled” for swap.

    Installing FreeBSD

    Following the instructions on the blog I created the freebsd-root and freebsd-swap partitions.

    Creating freebsd-root partition

    I created the root partition by selecting ada04p4 selecting [modify] then changing the default type from freebsd-ufs to freebsd-zfs Mountpoint: / Label: rootfs

    Creating freebsd-swap partition

    I then deleted the smaller 3.8GB ms-basic-data partition and create a new freebsd-swap partition. Type: freebsd-swap Size: 3920MB Label: swapfs

    Final partition table

    “After creating these custom partitions, the only thing left to do is remember to add hw.pci.enable_pcie_hp="0" to /boot/loader.conf before rebooting.”

    Post Installation

    After installing I was able to boot directly into FreeBSD. During the install I allowed the installer to delete and recreate the EFI partition. Since I used ZFS for the FreeBSD install, I didn’t need to change the fstab file. I also followed Adam’s lead and disabled hyper threading echo 'machdep.hyperthreading_allowed="0"' >> /boot/loader.conf I believe that it will improve single thread performance or something like that.

    I asked chatGPT and this was the answer:

    Disabling hyper-threading can have several advantages in certain scenarios:
    1. Improved Performance Stability: In some cases, especially with certain workloads or applications, disabling hyper-threading can lead to more stable performance. This is because hyper-threading can sometimes introduce overhead and contention for shared resources, which may impact performance under specific circumstances.
    2. Reduced Power Consumption: Disabling hyper-threading can lead to reduced power consumption since fewer logical cores are active, which may be desirable in environments where power efficiency is a priority.
    3. Potential Compatibility: Some applications or workloads may not be optimized for hyper-threading or may even exhibit issues when running on systems with hyper-threading enabled. Disabling hyper-threading can potentially improve compatibility with such applications.
    4. Better Resource Isolation: Disabling hyper-threading can help in scenarios where strict resource isolation is required between different tasks or virtualized environments. Without hyper-threading, each physical core behaves more independently, which can aid in resource isolation.
    5. Debugging and Troubleshooting: Disabling hyper-threading can also be useful in debugging and troubleshooting scenarios, especially when investigating performance issues or unexpected behavior that may be related to hyper-threading interactions.
    , , , , , ,

  • FreeBSD on Raspberry Pi with Bastille Jails

    FreeBSD on Raspberry Pi with Bastille Jails

    I was bored and I wanted a cheap, low power solution to test my bastille jails. For this reason I purchase Raspberry Pi 4B 8GB and the Nespi 4 Case. I already had a 1TB 2.5″ SSD laying around so I used that. First, I Installed FreeBSD on the Raspberry Pi and then I installed it inside the case. I selected the Nespi 4 case because it has an 2.5 SSD cartridge, it is cool looking, and it was $40 cheap.

    I followed this guide for proper zfs setup in FreeBSD: https://wiki.freebsd.org/ZFSTuningGuide

    To create the zfs volume on the SSD I followed this Vermaden guide: https://vermaden.wordpress.com/2023/04/10/silent-fanless-dell-wyse-3030-lt-freebsd-server/.

    Then for the jails I installed bastille and for the configuration I followed this guide: https://www.sharpwriting.net/project/bastille-jail-management-on-raspberry-pi-with-adguard/.

    At first, before I decided what I was going to do, I tried to bsdinstall FreeBSD on the SSD. I wanted to boot from SSD on a ZFS formatted pool. I read everything I could find on the internet to do this, and after many travails I was able to boot it, but it would then kernel panic. Instead of following this path I decided to keep the SD as it came, distributed by FreeBSD.org and use the SSD as zfs storage device instead. This solution is working so far.

    MicroSD Card Boot OS

    • Downloaded and burned FreeBSD-13.2-RELEASE-arm64-aarch64-RPI.img.xz onto a 32GB SD Card.
    • Booted to FreeBSD, changed the root password, created my user account and deleted the FreeBSD account.
    • Once mostly configured I created an Image of the SD Card as a backup.
    • I then made another backup of the SD card, fully configured. This way if the SD fails I can recover “quickly”, from another SD card.

    SD card Backups

    https://www.tweaking4all.com/hardware/raspberry-pi/macosx-apple-pi-baker/

    On my Mac I installed macOS-apple-pi-backer for easy imaging of the SD card and created the first image. I could have simply done this on my GhostBSD machine with dd, but the Mac has an SD card reader that works and was very convenient at that moment.

    The Configuration

    /boot/loader.conf

    In the /boot/loader.conf file, I added zfs entries recommended by the FreeBSD wiki ZFSTuningGuide

    # Configure USB OTG; see usb_template(4).
hw.usb.template=3
umodem_load="YES"
# Multiple console (serial+efi gop) enabled.
boot_multicons="YES"
boot_serial="YES"
# Disable the beastie menu and color
beastie_disable="YES"
loader_color="YES"
autoboot_delay="-1" #superfluous 
##### ZFSTuningGuide
vfs.zfs.prefetch_disable="1"
vfs.zfs.txg.timeout="5"
###
vfs.zfs.arc_max="512M"
zfs_load="YES"

    /etc/sysctl.conf

    I also added zfs entries on /etc/sysctl.conf recommended by the FreeBSD wiki ZFSTuningGuide

    kern.maxvnodes=250000
vfs.zfs.write_limit_override=1073741824

    /etc/rc.conf

    On /etc/rc.conf, I changed the hostname, disabled dumpdev, enabled powerd, ntpd and enabled zfs.

    I also enabled bastille and pf (required for bastille to work).

    #hostname="generic"
hostname="NespiBSD"
ifconfig_DEFAULT="DHCP"
sshd_enable="YES"
sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
growfs_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"
#######################
powerd_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
#### ZFS
zfs_enable="YES"
zfsd_enable="YES"
zfs_load="YES"
#### Bastille
bastille_enable="YES"
cloned_interfaces="lo1"
ifconfig_lo1_name="bastille0"
#### PF
pf_enable="YES"

    Shell: ZSH

    I configured zsh as the system’s shell following the very nice guide by Vermaden.

    /usr/local/etc/zshrc

    ~/.zshrc

    SSD ZFS Volume

    The next step was to setup the ssd drive with a zfs pool for Bastille. I encrypted the SSD because it is “removable” and If I were to use this setup in a users home or business I would like to secure it as much as possible.

    Prepared a geli encrypted SSD HD volume:

    gpart destroy -F /dev/da0
dd if=/dev/zero of=/dev/da0 bs=1m status=progress count=10
gpart create -s GPT /dev/da0
gpart add -t freebsd-zfs -a 4k da0
geli init -s 4096 da0p1
geli attach da0p1

    Then I created the pool: nexus

    zpool create nexus /dev/da0p1.eli
zfs set compression=zstd nexus
zfs set atime=off nexus
zfs set recordsize=1m nexus
zfs create nexus/data
zfs set mountpoint=none nexus
zfs set mountpoint=/data nexus/data

    Now I can geli attach da0p1 and then zpool import nexus to mount the SSD.

    Bastille Install and Configuration

    I then installed Bastille from pkg and enabled it on /etc/rc.conf

    pkg install bastille
bastille_enable="YES"

    I configured bastille as follows:

    /usr/local/etc/bastille/bastille.conf

    ## default timezone
bastille_tzdata="America/New_York"   
    ## ZFS options
bastille_zfs_enable="YES"
bastille_zfs_zpool="nexus"
##
bastille_zfs_prefix="data/bastille"

    The sharpwriting blog recommended to create the bastille folder. If you forget to do this the Bastille script will fail supposedly, but I don’t think it was needed as Bastille created its own dataset inside nexus/data: nexus/data/bastille

    root@NespiBSD:/ # mkdir /data/bastille
root@NespiBSD:/ # chmod 0750 /data/bastille

    added the following to the /etc/rc.conf

    cloned_interfaces="lo1"
ifconfig_lo1_name="bastille0"

    then I started the cloned device

    service netif cloneup

    /etc/pf.conf

    I setup pf firewall as in the Bastille getting started guide

    ext_if="genet0"
set block-policy return
scrub in on $ext_if all fragment reassemble
set skip on lo
table <jails> persist
nat on $ext_if from <jails> to any -> ($ext_if:0)
rdr-anchor "rdr/*"
block in all
pass out quick keep state
antispoof for $ext_if inet
pass in inet proto tcp from any to any port ssh flags S/SA keep state<

    Since we geli encrypted the SSD, we need a way to automatically mount it. It defeats security but I need the convenience, at least while testing the setup. I may remove it and I will then have to manually enter the password on reboot. This would not be a big issue since the machine is a server that is supposed to always be on.

    /etc/rc.local

    geli attach -j /root/key da0p1
zpool import nexus

    and then I created a test jail and it worked!

    test jail

    bastille bootstrap 13.2-RELEASE update
    bastille create test-jail 13.2-RELEASE 10.122.123.5

    Now I can import some of the jails I made on a virtual machine in an M1 Mac and test to see if that could work…

    ,

  • drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080

    I’m getting these errors on my Lenovo T480s which (I believe) sometimes causes the machine to lock up.

    drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080 .

    I am using Freebsd 13.1

    and until 10 minutes ago here was my Xorg cofig:

    Section "Device"
Identifier "Card0"
Driver "intel"
Option "AccelMethod" "SNA"
Option "TearFree" "true"
BusID "PCI:0:2:0"
EndSection

    I researched the issue and eventually asked the infamous chat bot ai and here was the answer:

    The error message you’re seeing suggests that there may be an issue with the graphics hardware or driver on your laptop. The “drmn0” component of the message refers to the Direct Rendering Manager (DRM) subsystem, which is responsible for managing graphics hardware in the Linux kernel (FreeBSD also uses the Linux kernel).

    The error message specifically mentions “Fault errors on pipe A: 0x00000080”. The “pipe A” in this context refers to a display pipeline, which is responsible for rendering graphics to a particular output (e.g. your laptop’s built-in display or an external monitor). The “0x00000080” value is a bitfield that encodes specific error conditions that may have occurred on the pipeline.

    The configuration file you’ve posted appears to be an Xorg configuration file for the “intel” driver, which is a common driver for Intel graphics hardware. The “AccelMethod” and “TearFree” options are performance-related options that may improve graphics performance or reduce tearing on the display.

    There are a few things you can try to troubleshoot the issue:

    1. Update your graphics driver: Make sure you have the latest version of the “intel” graphics driver installed. On FreeBSD, you can use the “pkg” package manager to update your installed packages. You may also need to update your kernel to ensure compatibility with the latest driver.
    2. Check your hardware: The error message suggests that there may be a hardware issue with your graphics hardware. You can run hardware diagnostics to check for any issues.
    3. Check your system logs: Look for any other error messages in your system logs that may be related to the graphics hardware or driver. This may help narrow down the issue.
    4. Disable graphics acceleration: You can try disabling graphics acceleration by removing the “AccelMethod” option from your Xorg configuration file. This may reduce performance, but may also help prevent the error from occurring.
    5. Seek professional help: If you’re not comfortable troubleshooting the issue on your own, or if the issue persists after trying the above steps, you may want to seek help from a professional technician or support service.
    pciconf -l -v | grep -A 4 vgapci
    vgapci0@pci0:0:2:0: class=0x030000 rev=0x07 hdr=0x00 vendor=0x8086 device=0x5917 subvendor=0x17aa subdevice=0x2258
vendor = 'Intel Corporation'
device = 'UHD Graphics 620'
class = display
subclass = VGA

    The output you’ve provided is the result of the pciconf command with options -l -v and the output has been piped to grep with the -A 4 option to display the 4 lines after each match.

    The output indicates that your laptop has an Intel UHD Graphics 620 integrated graphics card, which is manufactured by Intel Corporation. The device is located at pci0:0:2:0 and is identified by the class=0x030000 code, which indicates that it is a display controller.

    The rev=0x07 field in the output indicates the revision number of the device, while the hdr=0x00 field indicates that the device has a standard header. The subvendor and subdevice fields show that the device is integrated into a system made by Lenovo, with a device ID of 0x2258.

    Overall, this output confirms that your laptop has an Intel UHD Graphics 620 graphics card, and is useful information for troubleshooting graphics-related issues.

    What is the best driver for the UHD Graphics 620 on my Lenovo T480s running FreeBSD?

    The best driver for the Intel UHD Graphics 620 on your Lenovo T480s running FreeBSD is likely to be the drm-kmod kernel module. This module provides kernel-level support for graphics hardware and is the recommended way to enable hardware acceleration on FreeBSD.

    To use the drm-kmod module, you will need to make sure that your FreeBSD installation is up-to-date and that the module is installed. You can check whether the module is installed by running kldstat | grep -i drm. If the output shows that the drm and i915kms modules are loaded, then you already have the drm-kmod module installed.

    If the module is not installed, you can install it using the pkg package manager by running pkg install drm-kmod. Once the module is installed, you can load it using the kldload command: kldload drm.

    After loading the module, you may also need to configure your Xorg server to use the modesetting driver, which is the recommended driver for modern Intel graphics hardware. You can do this by creating a file called /usr/local/etc/X11/xorg.conf.d/20-intel.conf with the following contents:

    Section "Device"
  Identifier "Intel Graphics"
  Driver "modesetting"
EndSection

    What is the difference between the “intel” and “modesetting”drivers?

    The Driver "intel" and Driver "modesetting" are two different Xorg display drivers that can be used with Intel graphics cards.

    The intel driver is a legacy driver that is designed specifically for Intel graphics hardware and provides accelerated 2D and 3D rendering. This driver has been part of the Xorg project for many years and has generally provided good performance and stability on Intel hardware. However, it is no longer under active development and has been replaced by the modesetting driver in recent versions of Xorg.

    The modesetting driver, on the other hand, is a newer driver that is designed to be a universal driver for modern graphics hardware. It is a generic driver that works with any graphics card that supports the kernel mode setting (KMS) API, including Intel graphics hardware. The modesetting driver does not provide accelerated 3D rendering, but it does provide basic 2D acceleration and is generally more stable and reliable than the intel driver.

    In summary, the main difference between the intel and modesetting drivers is that the intel driver is a legacy driver that provides accelerated 2D and 3D rendering for Intel hardware, while the modesetting driver is a newer, universal driver that provides basic 2D acceleration and is designed to work with any graphics hardware that supports KMS. If your hardware is well-supported by the modesetting driver, it is generally recommended to use that driver over the intel driver.

    The intel driver has not been “stopped” from being developed, but it is no longer under active development by the Xorg project, which maintains the driver. The reason for this is that the Xorg project has shifted its focus to the modesetting driver, which is a more modern and universal driver that supports a wider range of hardware, including Intel graphics hardware.

    The intel driver is a legacy driver that was designed specifically for Intel graphics hardware, and it has been part of the Xorg project for many years. While the driver has generally provided good performance and stability on Intel hardware, it has also had some limitations and drawbacks. For example, the driver has had issues with some newer Intel hardware, and it has not always been well-maintained or kept up-to-date with the latest features and optimizations.

    The modesetting driver, on the other hand, is a more modern and universal driver that is designed to work with any graphics hardware that supports the kernel mode setting (KMS) API. The driver provides basic 2D acceleration and is generally more stable and reliable than the intel driver. It is also under active development and is being continually improved and updated with the latest features and optimizations.

    Overall, the shift away from the intel driver and towards the modesetting driver is part of a broader trend towards simplifying and modernizing the Xorg display system, and it reflects the Xorg project’s focus on providing a stable, reliable, and future-proof display system for all users.

    I lose 3D rendering under the modesetting driver? does this affect gaming and video?

    Yes, the modesetting driver does not provide accelerated 3D rendering, which means that you may experience reduced performance in 3D applications such as games, as well as video playback that relies on hardware acceleration.

    That being said, it’s important to note that the performance impact of using the modesetting driver for gaming and video playback will depend on the specific hardware and software being used, as well as the particular games or videos being played. In some cases, you may not notice a significant difference in performance between the intel and modesetting drivers, especially if your hardware is not very demanding.

    If you need to use your system for gaming or other 3D applications, and you find that the modesetting driver is not providing acceptable performance, you may want to consider using the intel driver instead. However, you should be aware that the intel driver is a legacy driver and may not be as reliable or stable as the modesetting driver, especially on newer hardware.

    Overall, the choice of driver will depend on your specific needs and priorities. If you prioritize stability and reliability over 3D performance, the modesetting driver is likely the best choice. If you prioritize 3D performance and are willing to accept some potential stability issues, the intel driver may be a better choice.

    Option “AccelMethod” “glamor”

    You recommended :

    "Device" Identifier "Intel Graphics"
Driver "modesetting"

    Why not also use these options?

    Option "DPMS"
Option "AccelMethod" "glamor"

    Both of the modesetting device sections you provided should work, and the choice between them is largely a matter of personal preference.

    The first device section you provided also omits the DPMS and AccelMethod options, which are both set to their default values by the modesetting driver. If you don’t need to change these options, it’s perfectly fine to omit them from your configuration file.

    The second device section you provided sets the AccelMethod option to “glamor”, which is an alternative 2D acceleration method that can be used by the modesetting driver. This option may provide slightly better performance than the default AccelMethod of glamor, but it can also cause stability issues on some hardware.

    In general, I would recommend starting with the simpler device section that doesn’t specify any additional options, and then adding options only if you encounter performance or stability issues. This will help ensure that your Xorg configuration is as simple and reliable as possible, while still providing good performance and functionality.


    Conclusion:

    I initially had started with the modesetting video driver, but I have also seen drm errors using it, so I had changed to the intel driver as a test. From now on I will be using the modesetting driver and report back here is I encounter errors/freezes.

    , , , ,

  • Wireguard server + wireguard-ui on a Mac Pro

    I wanted to have this nice wireguard ui working on a Mac Pro server I mangage. And I did. I previously set it up on a FreeBSD server and created the pertinet scripts for FreeBSD. I also posted them on the github page: https://github.com/ngoduykhanh/wireguard-ui/issues/264

    Here is how I did it:

    I first installed wireguard-ui, because I needed to make certain I could compile it on the Mac Pro, because otherwise there would be no point in installing wireguard-tools, I could simply instead run wireguard server from the MacOS wireguard GUI, because thats way easier and it works. I tested it recently following the instructions on this guide: https://docs.oakhost.net/tutorials/wireguard-macos-server-vpn/ …it works pretty well. Still it would be nice to have a web accessible ui, so I did.

    Install wireguard-ui

    I cloned the repository into /usr/local/

    cd /usr/local/
git clone https://github.com/ngoduykhanh/wireguard-ui.git

    Tested running ./init.sh

    But it returned an error, missing jq as a dependency. Then I ran ./prepare_assets.sh which obviously I should have run first. It found that I was missing yarn and node. After installing all missing dependencies I was able to build and run wireguard-ui

    Here is what I did to build wireguard-ui

    brew install jq
brew install yarn
brew install node
/usr/local/wireguard-ui$ ./prepare_assets.sh
go build -o wireguard-ui

    I then created an environment variables file so I could run and test it.

    # cat /usr/local/wireguard-ui/env

    #/usr/local/bin/bash

WGUI_USERNAME="admin user"
WGUI_PASSWORD="1password"
SMTP_HOSTNAME="smtp.gmail.com"
SMTP_PORT="587"
SMTP_USERNAME="someone@email.com"
SMTP_PASSWORD="1timepassword"
SMTP_NO_TLS_CHECK="true"
SMTP_AUTH_TYPE="LOGIN"
EMAIL_FROM_NAME="WireGuard-UI"
EMAIL_FROM_ADDRESS="someone@email.com"
WGUI_DNS="10.0.0.201"
WGUI_CONFIG_FILE_PATH="/usr/local/etc/wireguard/wg0.conf"
WGUI_SERVER_INTERFACE_ADDRESSES="10.04.35.0/24"

    The test worked.

    Install Wireguard

    After installing and testing wireguard-ui, I installed wireguard on the Mac Pro following this guide: https://barrowclift.me/post/wireguard-server-on-macos. I used it mostly as a guideline since I want to manage wireguard using wireguard-ui

    brew install wireguard-tools

    macOS
    This runs on macOS using the utun driver. It does not yet support sticky sockets, and won’t support fwmarks because of Darwin limitations. Since the utun driver cannot have arbitrary interface names, you must either use utun[0-9]+ for an explicit interface name or utun to have the kernel select one for you. If you choose utun as the interface name, and the environment variable WG_TUN_NAME_FILE is defined, then the actual name of the interface chosen by the kernel is written to the file specified by that variable.

    Installed wireguard-tools which is the best choice for wireguard-ui since both are implemented in go, and it makes the wireguard-ui dashboard happy as it displays active connections, yay.

    postup.sh & postdown.sh

    Then I created the directory where post up and post down scripts copied from this guide will live:

    sudo mkdir /usr/local/etc/wireguard
sudo chmod 644 /usr/local/etc/wireguard
    # cat /usr/local/etc/wireguard/postup.sh
    #!/bin/sh

# 1) This ensures our peers continue to report their Wireguard
#    assigned IPs while connected to the VPN. This is required
#    for their traffic to get routed correctly by the firewall
#    rules we crafted earlier with pf.
/usr/sbin/sysctl -w net.inet.ip.forwarding=1
/usr/sbin/sysctl -w net.inet6.ip6.forwarding=1

# 2) Preparing the directory where we'll persist the pf tokens
#    generated by Step (3) & (4). That token can then be used by
#    our postdown.sh script to remove the routing rules when
#    Wireguard is shut down.
mkdir -p /usr/local/var/run/wireguard
chmod 700 /usr/local/var/run/wireguard

# 3) Dynamically add the IPv4 NAT rule, enable the firewall,
#    increase its reference count (-E), and persist the reference
#    token generated by the command into
#    pf_wireguard_token_ipv4_token.txt, which postdown.sh will
#    reference when Wireguard is shut down.
echo 'nat on en0 from 10.0.10.1/24 to any -> (en0)' | \
        pfctl -a com.apple/wireguard_ipv4 -Ef - 2>&1 | \
        grep 'Token' | \
        sed 's%Token : \(.*\)%\1%' > /usr/local/var/run/wireguard/pf_wireguard_ipv4_token.txt
IPV4_TOKEN=`sudo cat /usr/local/var/run/wireguard/pf_wireguard_ipv4_token.txt`
echo "Added PF IPv4 NAT traffic routing rule with token: ${IPV4_TOKEN}"

# 4) Dynamically add the IPv6 NAT rule, enable the firewall,
#    increase its reference count (-E), and persist the reference
#    token generated by the command into
#    pf_wireguard_token_ipv6_token.txt, which postdown.sh will
#    reference when Wireguard is shut down.
echo 'nat on en0 from fd77:77:77:77::1/112 to any -> (en0)' | \
        pfctl -a com.apple/wireguard_ipv6 -Ef - 2>&1 | \
        grep 'Token' | \
        sed 's%Token : \(.*\)%\1%' > /usr/local/var/run/wireguard/pf_wireguard_ipv6_token.txt
IPV6_TOKEN=`sudo cat /usr/local/var/run/wireguard/pf_wireguard_ipv6_token.txt`
echo "Added PF IPv6 NAT traffic routing rule with token: ${IPV6_TOKEN}”

    # cat /usr/local/etc/wireguard/postdown.sh
    #!/bin/sh

# 1) Reverting our previously set IP forwarding overrides
/usr/sbin/sysctl -w net.inet.ip.forwarding=0
/usr/sbin/sysctl -w net.inet6.ip6.forwarding=0

# 2) Remove the IPv4 filter rule by reference. Adding and
#    removing rules by references like this will automatically
#    disable the packet filter firewall if there are no other
#    references left, but will leave it up if there are.
ANCHOR="com.apple/wireguard_ipv4"
pfctl -a ${ANCHOR} -F all || exit 1
echo "Removed IPv4 rule with anchor: ${ANCHOR}"
IPV4_TOKEN=`sudo cat /usr/local/var/run/wireguard/pf_wireguard_ipv4_token.txt`
pfctl -X ${IPV4_TOKEN} || exit 1
echo "Removed reference for token: ${IPV4_TOKEN}"
rm -rf /usr/local/var/run/wireguard/pf_wireguard_ipv4_token.txt
echo "Deleted IPv4 token file"

# 3) Remove the IPv6 filter rule by reference. Adding and
#    removing rules by references like this will automatically
#    disable the packet filter firewall if there are no other
#    references left, but will leave it up if there are.
ANCHOR="com.apple/wireguard_ipv6"
pfctl -a ${ANCHOR} -F all || exit 1
echo "Removed IPv6 rule with anchor: ${ANCHOR}"
IPV6_TOKEN=`sudo cat /usr/local/var/run/wireguard/pf_wireguard_ipv6_token.txt`
pfctl -X ${IPV6_TOKEN} || exit 1
echo "Removed reference for token: ${IPV6_TOKEN}"
rm -rf /usr/local/var/run/wireguard/pf_wireguard_ipv6_token.txt
echo "Deleted IPv6 token file"

    configuration file

    created an empty config file.
    /usr/local/etc/wireguard/wg0.conf

    Generated keys for the server

    $ cd /usr/local/etc/wireguard
$ umask 077 # Ensure credentials don't leak from possible race condition.
$ sudo su
$ wg genkey | tee privatekey | wg pubkey > publickey

    In the end I ended up having wireguard-ui generate the config file since that’s how wireguard-ui is supposed to work, basically it manages that file (/usr/local/etc/wireguard/wg0.conf) and adds tracking code.

    Now that I had both wireguard-tools and wireguard-ui installed I needed to create the launchctl scripts that will launch both processes at boot. The magic part being having my wireguard server restart every time wireguard-ui makes a change to /usr/local/etc/wireguard/wg0.conf. Here is how I managed to do it.

    LaunchDaemons

    com.wireguard.server.plist

    Fist I created a com.wireguard.server.plist to manage starting the server at boot just like in this guide: https://barrowclift.me/post/wireguard-server-on-macos. But This would not work for me since I need it to restart every time wireguard-ui makes changes to wg0.conf.

    com.wireguard-ui.plist

    <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
        "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.myapp.wireguard-ui</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/wireguard-ui/wireguard-ui</string>
  </array>
  <key>WorkingDirectory</key>
  <string>/usr/local/wireguard-ui/</string>
  <key>EnvironmentVariables</key>
  <dict>
    <key>WGUI_USERNAME</key>
    <string>not_parsed</string>
    <key>WGUI_PASSWORD</key>
    <string>not_parsed</string>
    <key>SMTP_HOSTNAME</key>
    <string>smtp.gmail.com</string>
    <key>SMTP_PORT</key>
    <string>587</string>
    <key>SMTP_USERNAME</key>
    <string>eldapper@mail.com</string>
    <key>SMTP_PASSWORD</key>
    <string>1timepassword</string>
    <key>SMTP_NO_TLS_CHECK</key>
    <string>true</string>
    <key>SMTP_AUTH_TYPE</key>
    <string>LOGIN</string>
    <key>EMAIL_FROM_NAME</key>
    <string>WireGuard-UI</string>
    <key>EMAIL_FROM_ADDRESS</key>
    <string>eldapper@mail.com</string>
    <key>WGUI_DNS</key>
    <string>10.0.0.201</string>
    <key>WGUI_CONFIG_FILE_PATH</key>
    <string>/usr/local/etc/wireguard/wg0.conf</string>
    <key>WGUI_SERVER_INTERFACE_ADDRESSES</key>
    <string>10.10.0.0/24</string>
    <key>-wg-conf-template</key>
    <string>/usr/local/etc/wireguard/wg0.conf</string>
  </dict>
  <key>StandardOutPath</key>
  <string>/var/log/wireguard-ui.log</string>
  <key>StandardErrorPath</key>
  <string>/var/log/wireguard-ui.log</string>
  <key>RunAtLoad</key>
  <true/>
  <key>KeepAlive</key>
  <true/>
</dict>
</plist>

    Fix permissions & launch wireguard-ui

    sudo chown root:wheel /Library/LaunchDaemons/com.watch.wireguard-ui.plist
sudo chmod 644 /Library/LaunchDaemons/com.watch.wireguard-ui.plist
sudo launchctl load /Library/LaunchDaemons/com.watch.wireguard-ui.plist

sudo launchctl list | grep com.wireguard-ui

    com.watch.wireguard.plist

    I first tried simply using WatchPaths in the .plist, but I was having trouble with the wg-quick script

    wg-quick: Version mismatch: bash 3 detected, when bash 4+ required

    I tried everything I could try (in my infinite ignorance) to have the env variables read from the .plist before loading wg-quick so it would use brew’s version of bash instead of the ancient included macos version but to no avail.

    MacOS native (ancient) bash:

    /bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin21)
Copyright (C) 2007 Free Software Foundation, Inc.

    brew’s version of bash:

    /usr/local/bin/bash --version
GNU bash, version 5.2.15(1)-release (x86_64-apple-darwin21.6.0)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

    After much trial and error, consulting of google and chatbot-ai, I ended up changing the version of bash called by the wg-quick script itself as follows:

    Edit /usr/local/bin/wg-quick and change:

    From this:

    #!/usr/bin/env bash

    To this:

    #!/usr/local/bin/bash

    Then I installed fswatch since I’ve used it before and I know it works. Here is reference: https://stackoverflow.com/questions/1515730/is-there-a-command-like-watch-or-inotifywait-on-the-mac For this I used MacPorts.

    sudo port install fswatch

    Here is the final launchd script that both launches wireguard on startup and relaunches wireguard when wireguard-ui makes changes to the config:

    com.watch.wireguard.plist

    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.wireguard.server</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/bash</string>
    <string>-c</string>
    <string>
   /usr/local/bin/wg-quick up /usr/local/etc/wireguard/wg0.conf &&
    while true; do
      /opt/local/bin/fswatch -1 /usr/local/etc/wireguard/wg0.conf &&
      sleep 1 &&
      /usr/local/bin/wg-quick down /usr/local/etc/wireguard/wg0.conf &&
      /usr/local/bin/wg-quick up /usr/local/etc/wireguard/wg0.conf
    done
    </string>
  </array>
  <key>StandardErrorPath</key>
  <string>/var/log/wireguard-server.log</string>
  <key>StandardOutPath</key>
  <string>/var/log/wireguard-server.log</string>
  <key>RunAtLoad</key>
  <true/>
  <key>KeepAlive</key>
  <true/>
</dict>
</plist>

    Fix Permissions & launch Wireguard. 

    sudo chown root:wheel /Library/LaunchDaemons/com.watch.wireguard.plist
sudo chmod 644 /Library/LaunchDaemons/com.watch.wireguard.plist

sudo launchctl load /Library/LaunchDaemons/com.watch.wireguard.plist
sudo launchctl list | grep com.watch.wireguard

    Rotating those logs, or maybe just remove them completely.

    Both .plist create logs, I needed the logs while setting this up so I could see all the basic mistakes I made along the way. Logs are cool as you can see when things are happening, but they could get very big quickly and polute your hard drive with unessesary i/o and baggage. I decided to keep them for now, but maybe I will disable them later.

    /var/log/wireguard-ui.log

/var/log/wireguard-server.log

    sudo port install logrotate

     logrotate has the following notes:
    To use logrotate:

      * See 'man logrotate' for configuration options.

      * Enable daily log rotation with this command.

        $ sudo port load logrotate

      * To create your own startup item with non-default intervals, build logrotate
        without the startupitem variant (-startupitem), copy the example into place
        and edit to your liking, then load with launchctl when finished.

        $ sudo cp /opt/local/share/logrotate/org.macports.logrotate.plist.example /Library/LaunchDaemons/org.macports.logrotate.plist

        $ sudo launchctl load -w /Library/LaunchDaemons/org.macports.logrotate.plist
    # Add your logrotate scripts to this directory for convenient inclusion.
include /opt/local/etc/logrotate.d
     sudo port activate logrotate

    logrotate config

    /opt/local/etc/logrotate.d/wireguard-server.conf

    /var/log/wireguard-server.log {
    size 100k
    rotate 7
    nodateext ## ADD THIS LINE ##
    missingok
    notifempty
    compress
    compresscmd /usr/bin/bzip2
    compressext .bz2
    maxage 100
    sharedscripts
    create 664
}

    tested the config as follows:

    sudo logrotate -f /opt/local/etc/logrotate.d/wireguard-server.conf

    it worked as it created a .bz2 file:

    -rw-r--r-- 1 root wheel 918 Feb 16 14:56 wireguard-server.log.1.bz2

    /opt/local/etc/logrotate.d/wireguard-ui.conf

    /var/log/wireguard-ui.log {
    size 100k
    rotate 7
    nodateext ## ADD THIS LINE ##
    missingok
    notifempty
    compress
    compresscmd /usr/bin/bzip2
    compressext .bz2
    maxage 100
    sharedscripts
    create 664
}

    again tested the config as follows

    sudo logrotate -f /opt/local/etc/logrotate.d/wireguard-ui.conf

    -rw-r--r-- 1 root wheel 20018 Feb 16 15:04 wireguard-ui.log.1.bz2

    After all of this we have our working wireguard server using wireguard-ui as its interface. Nice!

    ,
    , ,

  • My FreeBSD Dashboard

    I saw this theme https://www.tumfatig.net/2022/give-windowmaker-a-macos-mojave-look/ and I decided that I needed the conky dashboard for my FreeBSD ThinkPad. I’m already using conky for a different dashboard developed by Vermaden: https://vermaden.wordpress.com/2019/03/20/freebsd-desktop-part-18-global-dashboard/ This would be a great addition to my “new” openbox desktop. Also, since I use wifibox as a solution FreeBSD’s lack of proper WiFi drivers, I neede a place to track it properly.

    This is the end result:

    I took the script from the TuM’Fatig blog and added Wifibox and iostat metrics.

    here is my version of the conky script:

    # conky(1)
#

background true

alignment tr
gap_x 40
gap_y 40
minimum_size 320 600
maximum_width 320

#gap_x                   288
gap_y                    100
border_inner_margin 20
border_outer_margin 0
border_width 0

default_color fefefe

draw_borders       no
draw_graph_borders yes
draw_outline       no
draw_shades        no

use_xft yes
#xftfont Sans:style=Medium:size=10
#xftfont                  Iosevka Fixed SS04
xftfont 		  ubuntu mono-10

#xftfont monospace:pixelsize=9
xftalpha .8

double_buffer true
text_buffer_size 1024

own_window yes
own_window_class conky
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
#own_window_hints = 'undecorated,sticky,below,skip_taskbar,skip_pager'
own_window_type        override
own_window_transparent no
own_window_argb_visual yes
own_window_argb_value 92

update_interval 5

TEXT
${font ubuntu mono:Bold:size=10}${voffset 5}${alignc}${exec uname -s} ${exec freebsd-version}${font}

CPU  ${voffset 5}${cpubar cpu0 3}
Speed ${alignr}${freq_g}GHz
Temperature ${alignr}\
${exec sysctl -n sysctl dev.cpu.0.temperature | sed -e 's/\..*$/°C/'}

RAM  ${voffset 5}${membar 3}
Used ${alignr}${mem}
Total ${alignr}${memmax}

SWAP  ${voffset 5}${swapbar 3}
Used ${alignr}${swap}
Total ${alignr}${swapmax}

NETWORK  ${hr 1}

#Public IP: ${alignr}${exec wget -qO - http://wtfismyip.com/text}
Ethernet ${alignr}${exec ifconfig  em0| awk '/status/ { $1=""; print $0 }'}cBastille ${alignr}${exec ifconfig bastille0 | grep "inet " | awk '{print $2}' }
WifiBox ${alignr}${exec ifconfig wifibox0| awk '/inet/ { print $2 }'}
WifiBoxIP ${alignr}${cat /tmp/wifibox_ip}
Signal ${alignr}${cat /tmp/wifibox_signal_strenght}
Upload   ${alignr}${upspeed tap0}
Download ${alignr}${downspeed tap0}

PROCESS  ${hr 1}

Name${goto 256}CPU${goto 316}MEM  
${top name 2}${font ubuntu mono:size=10}${goto 228}${top cpu 2}%${goto 290}${top mem 2}%${font}
${top name 1}${font ubuntu mono:size=10}${goto 228}${top cpu 1}%${goto 290}${top mem 1}%${font}
${top name 2}${font ubuntu mono:size=10}${goto 228}${top cpu 2}%${goto 290}${top mem 2}%${font}
${top name 3}${font ubuntu mono:size=10}${goto 228}${top cpu 3}%${goto 290}${top mem 3}%${font}
${top name 4}${font ubuntu mono:size=10}${goto 228}${top cpu 4}%${goto 290}${top mem 4}%${font}
${top name 5}${font ubuntu mono:size=10}${goto 228}${top cpu 5}%${goto 290}${top mem 5}%${font}

IOSTAT ${hr 1}
${font ubuntu mono:size=9}${exec zpool iostat -L }${font}

${hr 1}

${alignc}${time %H:%M} ${time %A} ${time %d %B, %Y}

    These are my additions to the config file:

    Bastille ${alignr}${exec ifconfig bastille0 | grep "inet " | awk '{print $2}' }

WifiBox ${alignr}${exec ifconfig wifibox0| awk '/inet/ { print $2 }'}

WifiBoxIP ${alignr}${cat /tmp/wifibox_ip}

Signal ${alignr}${cat /tmp/wifibox_signal_strenght}
    1. Bastille
    2. wifibox0 IP assigned by the wifibox-alpine bhyve vm.
    3. Signal strength
    4. IP address of the WiFi connection.

    I use a jail in Bastille as my DNS server. For this reason I need to see that the IP is up. Number 2 is the IP assigned to my computer by wifibox. If I see that IP it usually means wifibox is up and running. The following is an entry for signal strength. This is a crucial metric. We all need to know how far away or how close we are to the WiFi AP.

    4 is important as I want to be able to see what IP I have been assigned by the WiFi router. Since this IP is assigned to the wifibox alpine vm, I would otherwise have to run a terminal command to get it.

    In other to get entries 3 and 4 to work I wrote a simple script that pools the information through wpa_cli:

    __get_wifibox_data.sh

#!/bin/sh

while true; do
  wpa_cli status | grep "ip_address" | awk '{ sub("ip_address=", "", $1); print $1 }' > /tmp/wifibox_ip
  ~/bin/wifi_strength.sh > /tmp/wifibox_signal_strenght
  sleep 5
done

    I also had to write a simple script to convert the SSR1 signal strength to a percentage:

    wifi_strength.sh

#!/bin/sh

RSSI=`wpa_cli signal_poll | grep "RSSI" | awk '{ print $1}' | awk -F= '{print $2}' | head -1`
if [ $RSSI -ge -50 ] ; then
  PERCENTAGE=100
elif [ $RSSI -lt -90 ] ; then
  PERCENTAGE=0
else
  PERCENTAGE=$(echo "(($RSSI+90)*100)/40" | bc)
fi
echo $PERCENTAGE%

    I am not a programmer but I like to try. If you find anything wrong with this approach please let me know. Also, I hope this is useful for someone.

    , ,

  • Cron job for when devd fails to renew wifibox0 IP, so that connection is re-established after waking from sleep.

    For some reason, beyond my knowledge and understanding. The ACPI resume entry in devd works, and the wifibox0 interface renews it’s IP: 10.0.0.2. The problem is that it only works for abut a minute or 2 then it disconnects. Sometimes it disconnects in seconds as depicted below:

    I am not sure what is causing it to disconnect but I do see webcamd trying to reconnect at the same time… I can manually run dhclient wifibox0 to reconnect or doas service netif restart wifibox0 to do the same, but I want this to happen automatically and by itself. My solution was to write a simple script and run it every minute with cron.

    My script:

    cat ~/bin/wifibox_inet.sh

    #!/bin/sh
interface=wifibox0
IP=$(ifconfig $interface | grep inet)
if [ -z "$IP" ]; then
logger "There is no wifibox0 IP!"
#    doas dhclient -r $interface
    doas dhclient $interface
fi

    The cron entry:

      * * * * * ~/bin/wifibox_inet.sh

    “At every minute.”

    Now when I wake the laptop from sleep I will have network connectivity within a minute of doing so.

    , , ,

  • Wifibox on my GhostBSD laptop

    Tired of having issues with WiFi connectivity when using my Dell Lattitude 5591 laptop I decided to investigate Wifibox as a solution. Now I have been using it for almost a week and I have to say that for FreeBSD, this is the way.

    Project FreeBSD Wifibox: https://github.com/pgj/freebsd-wifibox

    Wifibox deploys a Linux guest to drive a wireless networking card on the FreeBSD host system with the help of PCI pass-through. There have been guides on the Internet to suggest the use of such techniques to improve the wireless networking experience on FreeBSD, of which Wifibox tries to implement as a single easy-to-use software package.

    Installation

    I installed Wifibox using the GhostBSD Software Station:

    I simply searched for “wifibox” and the dependencies followed:

    • grub2-bhyve
    • socat
    • wifibox
    • wifibox-alpine
    • wifibox-core

    Configuration:

    After the installation to the system, check the sample configuration files provided in the /usr/local/etc/wifibox directory and follow the instructions to create a working configuration, otherwise wifibox will refuse to start. For systems that might be put in sleep mode, e.g. laptops, there is a sample devd.conf(5) configuration file in the /usr/local/etc/devd directory that can be used to restart wifibox on resume.

    get wifi card specs:

    I used pciconf -lBbcevV iwm0 to get the pci address of my Wi-Fi card

    iwm0: <Intel(R) Dual Band Wireless AC 9560>
    iwm0@pci0:0:20:3

    Then I added it to the bhyve.conf file

    Wifibox configuration

    cat /usr/local/etc/wifibox/bhyve.conf

    cpus=1
    memory=128
    console=yes
    passthru=0/20/3

    I edited the provided devd/wifibox.conf file so that Wifibox continues to work after putting the laptop to sleep. I copied these settings from the discussions on the wifibox github page. These settings have been working for me so far.

    cat /usr/local/etc/devd/wifibox.conf

    # This is a `devd(8)` configuration file to run the resume action of

# wifibox on the ACPI resume event. Review the contents and create a

# copy of it without the `.sample` extension to use it. Restart the
# `devd` service once the file has been created.

notify 11 {
match "system" "ACPI";
match "subsystem" "Suspend";
action "logger 'Stopping wifibox before suspend' && /usr/local/sbin/wifibox stop && /etc/rc.suspend acpi $notify";
};

notify 11 {    
match "system" "ACPI";    
match "subsystem" "Resume";    
action "/etc/rc.resume acpi $notify && logger 'Starting wifibox after resume and getting IP via DHCP' && /sbin/kldunload vmm && /sbin/kldload vmm && /usr/local/sbin/wifibox start guest && /sbin/dhclient wifibox0";
};

    The next file I edited was the /usr/local/etc/wifibox/wpa_supplicant/wpa_supplicant.conf file. All I had to do was copy over the WiFi settings for my connection from the FreeBSD /etc/wpa_supplicant.conf file

    Next configure the Host:

    Disable local WiFi and enable Wifibox

    By default, PCI pass-through is disabled for AMD-based hardware, hence it must be explicitly enabled via the corresponding syctl(8) variable. This can be done by adding the following line to either /etc/sysctl.conf or /boot/loader.conf depending on whether vmm(4) is going to be loaded by wifibox or it is already loaded at boot.

    added this line to /boot/loader.conf

    # Wifibox
    hw.vmm.amdvi.enable=1

    In order to make wifibox work as a system service, the following line has to be added to rc.conf(5).

    wifibox_enable="YES"

    At the same time, make sure that no FreeBSD driver is configured for the same device and remove all the related settings from there. The devmatch(8) utility might be used to stop any conflicting drivers from loading automatically. For example, the iwm(4) and iwlwifi(4) native drivers could be disabled in rc.conf(5) as shown below.

    devmatch_enable="YES"
    devmatch_blocklist="if_iwm if_iwlwifi"

    I made the following changes to my /etc/rc.conf file:

    Disabled local wifi:

    #WiFi
    #wlans_iwm0="wlan0"
    #ifconfig_wlan0="WPA DHCP"
    #create_args_wlan0="wlanmode sta regdomain FCC country US"
    ##wlandebug_wlan0="+state +node +auth +assoc +dot1xsm +wpa +scan"

    Enabled Wifibox service:

    #wifibox
    wifibox_enable="YES"
    devmatch_enable="YES"
    devmatch_blocklist="if_iwm if_iwlwifi"
    #DHCP
    ifconfig_wifibox0="SYNCDHCP"
    background_dhclient_wifibox0="YES"
    defaultroute_delay="0"
    # end wifibox

    This is how /etc/rc.conf looks on my terminal emulator:

    Using Wifibox

    The wifibox0 networking interface can be brought up with the use of the netif service.
    # service netif start wifibox0
    For static IP address configurations, the routing service has to be restarted as well.
    # service routing restart

    After configuring Wifibox and GhostBSD to use Wifibox I restarted my computer. Then I ran:

    #service netif start wifibox0

    and Wifibox instantly connected to my WiFi! To verify that Wifibox was working as intended. I ran a speed test and was able to get the fastest speed available on my WiFi network connection and hardware:

    Idle Latency: 6.47 ms (jitter: 0.84ms, low: 5.83ms, high: 7.14ms)

    Download: 556.38 Mbps (data used: 982.2 MB)
    20.03 ms (jitter: 16.97ms, low: 8.80ms, high: 286.34ms)

    Upload: 235.55 Mbps (data used: 229.0 MB)
    11.10 ms (jitter: 5.34ms, low: 5.31ms, high: 32.83ms)

    Packet Loss: 0.0%

    Connect WiFi box on login/restart:

    Every time the computer is logged off or restarted the networking interface needs to be manually brought up:
    # service netif start wifibox0

    This is a PITA of course so I created a simple script
    ~/scripts/wifibox_restart.sh

    #!/bin/sh
    doas service routing restart
    doas service netif restart wifibox0

    which I added to my
    System > Preferences > Personal > Startup Applications

    Now when I log in, the startup script re-establishes the connection. The last caveat is what happens when I set the machine to sleep and wake it back up. The wifibox0 interface fails to reconnect. So I added a menu item so I can easily bring the interface back up and connect to the network:

    Findings

    Never issue a service wifibox restart. This freezes the computer. Sometimes service wifibox restart guest works. Most times it also freezes the computer and restarts it.

    Best way to manage Wifibox is to use the console and issue commands there. These are a few examples of the commands I use:

    wpa_supplicant tool has its own associated service and it can be checked by the following command.

    # rc-service wpa_supplicant status

    Sometimes it is connected to the wrong Access Point (I have 3 at the house) and I need it to reconnect quickly I may just restart Wifibox from the console:

    # rc-service networking restart

    I hope this helps someone…

    Edit #1

    Another way to bring the wifibox0 interface is to create a /etc/rc.local script. This file probably doesn’t exist on your machine because its the old way of doing rc scripting but this seems to be the easiest way to have wifibox work upon restart of the machine.

    For some reason on reboot the the wifibox0 interface fails to get an IP from DHCP, seems to be because the interface doesn’t exist before the bhyve VM is started, work around until I find a solution:

    Edit `/etc/rc.local’:

    /sbin/dhclient wifibox0

    Reboot, all should be good

    https://forums.sheridancomputers.co.uk/t/how-to-setup-wifibox-on-freesbd/102
    Edit #2

    To reliably have the WiFi connection working upon waking from sleep we need to re-edit the /usr/local/etc/devd/wifibox.conf Thanks to q-pa https://github.com/pgj/freebsd-wifibox/issues/31#issuecomment-1698575652

    notify 11 {
    match "system" "ACPI";
    match "subsystem" "Resume";
    action "/etc/rc.resume acpi $notify && logger 'Starting wifibox after resume and getting IP via DHCP' && /sbin/kldunload vmm && /sbin/kldload vmm && /usr/local/sbin/wifibox start guest && /sbin/dhclient wifibox0";
    };

    ,
    , , ,

  • Allowing ssh through wifibox

    Wifibox is an amazing solution to FreeBSD’s lack of good properly working wifi drivers. It also isolates your network connection enabling no access back to the machine. Currently I can ssh in via the wireguard IP of an automatic connection to a wireguard server I have setup. But this is slow and not ideal since it means I have to go out to the internet to get to my GhostBSD laptop. LOL

    I needed to be able to SSH directly, so I researched it and found the iptables solution:

    https://github.com/pgj/freebsd-wifibox/issues/18#issuecomment-1206780431

    I applied the following rule in order to get this working (This isn’t a permanent solution but will help):(Applied inside the VM.. which is read-only but you can still manipulate the IP table):

    iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to-destination 10.0.0.2:22

    Once you do that and test that you can reach whatever service you need on the host side (from another machine), you can do the following in the VM to get the final rules:

    iptables-save

    wifibox login: root
    wifibox:~# iptables -t nat -A PREROUTING -p tcp --dport 22 -j DNAT --to-destinat
    ion 10.0.0.2:22
    wifibox:~# iptables-save

    #Generated by iptables-save v1.8.8 on Sun Jan 15 17:08:24 2023
    *nat
    :PREROUTING ACCEPT [4:418]
    :INPUT ACCEPT [3:342]
    :OUTPUT ACCEPT [0:0]
    :POSTROUTING ACCEPT [1:64]
    -A PREROUTING -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.2:22
    -A POSTROUTING -o wlan0 -j MASQUERADE
    COMMIT
    #Completed on Sun Jan 15 17:08:24 2023
    #Generated by iptables-save v1.8.8 on Sun Jan 15 17:08:24 2023
    *filter
    :INPUT ACCEPT [50:4432]
    :FORWARD ACCEPT [292:43425]
    :OUTPUT ACCEPT [6:980]
    -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -i eth0 -o wlan0 -j ACCEPT
    COMMIT
    #Completed on Sun Jan 15 17:08:24 2023

    From there I grabbed the one line I needed to edit the  /usr/local/etc/wifibox/appliance/iptables file. Its applied upon restarting the VM again.

    (The one line that translates to the above yields: -A PREROUTING -p tcp -m tcp --dport 22 -j DNAT -to-destination 10.0.0.2:22 and goes under the :POSTROUTING ACCEPT [0:0] section of *nat)

    This is the resulting file:

     /usr/local/etc/wifibox/appliance

    # This file contains exported IP Tables data that can be read by the
# iptables-restore(8) utility.  It is not meant to be edited by hand
# but regenerated by the iptables-save(8) utility after the necessary
# changes were made via the respective iptables(8) commands.
#
# The IP Tables stored here implement a simplistic IP forwarding and
# NAT between the `eth0` (virtual Ethernet, facing towards the host)
# and `wlan0` (wireless networking) interfaces.

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
[0:0] -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
[0:0] -A FORWARD -i eth0 -o wlan0 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -p tcp -m tcp --dport 22 -j DNAT --to-destination 10.0.0.2:22
[0:0] -A POSTROUTING -o wlan0 -j MASQUERADE
COMMIT
    , ,
Design a site like this with WordPress.com
Get started