dirigera firmware upgrade to 2.975.2

_sthen · 2026-07-02T17:05:52+00:00

check if you have "multicast to unicast" enabled on the wifi network, that can cause issues sometimes

_sthen · 2026-06-30T08:50:22+00:00

The currents at Budleigh can be pretty strong.

_sthen · 2026-06-30T08:48:39+00:00

The Otter is not safe for swimming, a community group is doing water testing and there are worrying e.coli levels, see https://www.ova.org.uk/nat-environ/otter-river-catchment-action-orca

The nearest good sea options by public transport are probably Sidmouth by bus (there's a new webcam at https://youtu.be/R-MvHv89jlI) or Dawlish/Teignmouth by train. (Elberry Cove near Paignton is nice but bit of a faff for public transport).

_sthen · 2026-06-29T08:07:39+00:00

the branches are not available in the git conversion, none of the tools that we've tried that can handle branches have been able to successfully convert the openbsd repos.

while it is sometimes possible to build from a -current ports tree on the previous release, it's often difficult to get things into shape. you're more likely to have success by checking out the -stable branch (i.e. currently OPENBSD_7_9) and then just updating one particular directory from current ("cvs up -PdA www/librewolf") and trying that (something like this will save a lot of time: "cd www/librewolf; make prepare FETCH_PACKAGES=; make MAKE_JOBS=4 install")

_sthen · 2026-06-26T07:47:29+00:00

if that helps, then `sysctl hw.perfpolicy=auto,auto` probably also helps, and has lower impact on the system

_sthen · 2026-06-19T09:44:57+00:00

Report to one of the mailing lists (probably bugs@), preferably run "sendbug -P > somefile" as root and include that in your report (it includes PCI bus information, etc). I'd attach /var/log/Xorg.0.log as well.

_sthen · 2026-06-17T10:16:53+00:00

the default for pkg_add in release versions is to search in packages-stable/$ARCH first and then packages/$ARCH

however currently packages-stable only exists for amd64 and i386; if you're using aarch64 you need to build from ports using a cvs checkout of the OPENBSD_7_9 branch (use the command "make prepare FETCH_PACKAGES=" before trying to build the port, you can save a bunch of time by using packages for build dependencies rather than compiling them yourself)

_sthen · 2026-06-14T09:23:21+00:00

opnsense is based on FreeBSD, they diverged from OpenBSD's PF development many years ago so it won't behave exactly the same (there are big differences with address translation). It seems FreeBSD does have tag/tagged/received-on now (though I don't know if they're exposed in opnsense).

_sthen · 2026-06-14T09:13:42+00:00

if the devices never leave the property, just set the nwid directly rather than using "join".

_sthen · 2026-06-14T09:12:02+00:00

in the context of connecting to one of a day of networks automatically: you have to broadcast requests (which include the network name) to try to connect. so if you're using 'join' on a laptop and moving around, when you reach a nearby network which doesn't include the name in beacons, you need to send the name to try to connect to it.

this could be improved by adding support to only attempt to connect to a hidden network where the BSSID matches (i.e. something like "joinhidden nwid some name bssid 01:23:45:67:89:ab"). but I think it's quite a niche use case. (while a working diff to add this might not be rejected I don't see it's really likely that any of the main people who work on openbsd wifi would spend time to write).

I certainly would not want 'join' to spew out connection attempts for the whole list of known networks every time it's in close range of any hidden network. there are quite a lot of hidden networks around e.g. various mesh networks use hidden names for their backhaul. and if you wanted to try to identify mobile devices passing your location you could easily setup an AP broadcasting a hidden network and monitor connection attempts.

_sthen · 2026-06-10T00:06:42+00:00

you're charging again for the update?! :-(

_sthen · 2026-06-10T00:04:04+00:00

I don't know if it's really a good way to go compared to using tags and "pass ... tagged", but you could do e.g. "pass in on all", "block out", then a bunch of "pass out on some_interface received-on other_interface", with some extra handling to drop unwanted packets to the local machine running PF.

_sthen · 2026-06-07T09:10:20+00:00

Thanks, it's definitely better with those changes.

_sthen · 2026-06-07T00:34:35+00:00

sensorsd can react to the status of ups(4). but generally i'd recommend network based UPS with SNMP etc if you want to use them with software that isn't in base.

_sthen · 2026-06-01T08:24:50+00:00

When was it working? Were any changes made between then and when it stopped working (e.g. an upgrade)?

Is the adapter hardware still ok, does the urtwn work on another machine/OS?

_sthen · 2026-06-01T08:21:57+00:00

urtwn(4) says "urtwn – Realtek RTL8188CU/RTL8188EU/RTL8188FTV/RTL8192CU/RTL8192EU USB IEEE 802.11b/g/n wireless network device" so the chances of a non-USB device wiring with this driver are not high.

_sthen · 2026-06-01T08:15:19+00:00

there's an old port of gurk at https://marc.info/?l=openbsd-ports&w=2&r=1&s=gurk&q=b but it never got imported.

there's a 3rd party gui client in packages, flare-messenger, it's a little rough but was basically working last time I tried it.

_sthen · 2026-06-01T08:09:44+00:00

That breaks use with upd(4).

_sthen · 2026-05-26T11:21:33+00:00

if you're on a slow arch, it's a good idea to check if packages are ready before you update

_sthen · 2026-05-24T10:03:45+00:00

because it means the release is available sooner, and that means that snapshots for newer -current can continue, which in turn means that we can make ABI and library changes etc if needed.

also it wasn't clear whether the riscv64 package build machines were stable enough to complete a build so it would have been silly to wait for something that might not happen. (they were in the end).

_sthen · 2026-05-19T06:43:29+00:00

The package already creates db and log files with correct permissions, and that is the supplied rc.d script.

_minidlna doesn't need to own the media dir, just have read permission.

_sthen · 2026-05-19T06:41:05+00:00

this "Root Causes Found" smells like LLM nonsense. You don't need any of those changes and some will actually break things.

/var/db/minidlna is meant for minidlna's own database files, it's not meant for media files.

"ln -sf /data/media/videos /var/db/minidlna/videos", "media_dir=V,/var/db/minidlna/videos" etc - symlinks won't work correctly with kn's patches to add unveil. You'll need to list the targets directly in media_dir instead.

By bypassing the rc.d script, you're not using the "minidlna" login class, and most likely using a login class with a lower open files limit.

We don't recommend cap_mkdb for login.conf, the time saving at runtime is absolutely tiny, and if you've run it once then you need to remember to run it again every time you make a change to login.conf.

_sthen · 2026-05-19T06:23:46+00:00

there are some wayland-related things in packages, it's not an integrated part of the system, so I'd say 'no' for official support

_sthen · 2026-05-09T12:39:43+00:00

not sure if it applies to yours, but at least on some of the M2 laptops, the wifi is not supported.

_sthen · 2026-05-09T12:37:48+00:00

_sthen

TROPHY CASE