FYI, still an ftp issue, and it also affects the website apparently when you go to download via http (after selecting a version, you go to this URL, which hangs until timeout: freebsd.org/where)

East coast the server in question is 96.47.72.116/ftp0.nyi.freebsd.org

From a west coast VPS (SEA) I get a different server (204.15.11.67/ftp0.tuk.freebsd.org), which is reachable, but it just immediately closes the connection.

(specifically this error: 421 Service not available, remote server has closed connection.)

It's kind of odd there's no links to mirrors or the http download site on any pages linked from the "Get FreeBSD" menu item on the main FreeBSD website.

It would be good if whoever has control of the GeoDNS would drop the bad mirrors routing over to known good ones. No idea who that would be in the project though.

Kind of odd the east coast one is down as that's in their main NYI datacenter (if the hostname is to be believed).

Due to multiple mirrors having been identified as offline I doubt it is a datacenter problem. More likely it is a server side problem.

My ThinkPad has an atheros WLAN chip that is just out of the range man says is supported. I don't need openbsd as much as to write the driver myself, but would be happy to know when to check again.

mane yes, sup?

antranigv_: nothing atm xD

I think I solved my current issues

But you could tell me how to make my bad send mails to gamail

Teach me even

lw: btw, ip-transparent worked

hi, is there a way to separate cwd's of different threads within one process? on linux this can be done with unshare(CLONE_FS)

/28/54

good morning

Morning

EHLO

I need to get vscode working on FreeBSD 14.1. What are my options?

pkg install editors/vscode

holy gyatt it works just out of the box

maybe because I switched from quarterly to latest

🤷

Hi, do you recommend using autotools for packaging or just vanilla Makefiles? I have done my research. I want to know your opinions.

spmzt: I'm all for simplicity.

spmzt, It depends upon who is consuming your project code. I mostly use autoconf+automake (never libtool) to produce full featured Makefiles very simply.

Years ago I wrote a now ancient article which is my personal guide to using them simply which I guess I need to update now. proulx.com/~bob/doc/HOWTO-autotools.html

mason: that's what I thought first. Feels like unnecessary layer of indirection. But I have to learn it know for some reason...

rwp: Thanks! I will read your article now.

*now

Any tips on how to get a FreeBSD 14.1 VM running under 13.3 bhyve? Install worked but boot fails with a very odd message:

"zfs: unsupported feature: com.klarasystems:vdev_zaps_v2"

Googling that talks about a mismatch in boot blocks, but I literally just completed the 14.1 install, so I don't see how it can be outdated.

What's the backing store for the VM on 13.3? Are you using a zvol or a disk image raw file or?

For bhyve's "loader" I'm using "bhyveload" (I'm not really finding docs on which loader is used in which circumstances, I assume "bhyveload" for FreeBSD, "grub" for Linux, and the EFI stuff for graphical installs)

zvol

This is a very fuzzy area in my knowledge but I have been trying to understand it myself too.

I think the bhyveload method is taking a shortcut in that it is not creating a VM that is actually rebooting but is instead directly loading the VM kernel. Which causes the problem you are seeing when there are mismatched features.

spork_css: UEFI is for anything, bhyveload is an alternative specifically for FreeBSD which isn't really needed nowadays (although there's no harm in using it)

I think you need to use the newer 14 bhyveload on the older 13 bhyve in order to get this feature. I think.

That's the other option. Use uefi to boot. Possibly grub. Myself I don't like UEFI and so I would attempt grub first to get a legacy bios boot structure. But then try uefi.

Just for background are you using bhyve or a helper such as vm-bhyve?

rwp: I want to understand, why you don't use libtool? because of pkg-config or what?

spork_css: depending on what you're doing with that 14.1 VM, maybe use UFS instead of ZFS, if the bhyve host is on an older version of ZFS. ZFS on ZFS isn't that useful either iirc

spmzt, I don't like libtool. I think its main use is to support rpath which is a feature I think should never be used. So I don't use it.

But automake is useful because it allows a vary simple template to be expanded into a full featured Makefile. I like that so I do use it.

I don't have anything particularly against people maintaining their own full featured Makefile by hand. That's fine. But it's a lot of characters in the file that I would rather generate.

And if using automake then using autoconf supports automake most efficiently. And the combination then runs pretty much everywhere.

it seems wireguard doesn't attempt to reconnect when the initial attempt fails

so change of carrier, or after waking from suspend and reconnecting to wifi causes wireguard to break until you forcefully restart it

this is the kernel module and not wireguard-go

anyone having the same issue?

hi polarian , I don't have this issue on OpenBSD, must be FreeBSD specific. Haven't tried doing wireguard on that yet

hopefully people who use it daily can chime in

I will go to ML then

if I remember to :P

I have a lot of emails to write :(

unix.stackexchange.com/questions/31…e-and-extend-to-new-disk-in-freebsd <--this looks pretty sound

polarian: I can't confirm neither reproduce this

after wakeup wirguard works

mzar: if you disconnect from wifi and then reconnect, does your tunnel work again?

my wireguard tunnel never handshakes again...

moreover, there is no "connection" in wireguard

if I disable the tunnel the carrier works just fine

it just sends/receives encrypted packets

mzar: apologies yes... my point is when it it fails to handshake, it doesn't appear to attend a handshake again

maybe I should set a PersistentKeepalive

polarian: when I bring wlan0 down and up again, wireguard just works

good point

wtf?

let me try again

polarian: how do you find FreeBSD ? is it usable OS ?

weird it worked now... it was becoming painful at uni...

nope it didn't...

hello CCFL_Man, do you still run this infrasond monitorig on FreeBSD

it worked for 2-3 seconds after wlan0 came back up, and then nothing...

all packets dropped...

had to restart wireguard

that's sad story polarian, your wireguard setup seems to be borked

mzar: freebsd works decently wifi is a little annoying as I have to adjust the flags for wlan0 (remove WPA when in public and then add it again at home)

mzar: no clue why... works just fine on my phone and my server has no issues...

it's most likely the keep alive. If it's not there the connection might need to redone

mzar: i have not started yet. i realized the modifications i made to get Earthworm to build on FreeBSD might have broken things

I am aiming for always on vpn on my laptop but finding it difficult to find a way to do this on LAN

all packets should go via wireguard, but the carrier default gateway takes priority

if there are nat/firewall steps in between peers and there is a long disruption (e.g., sleep) then the connection might fail

I can disable DHCP but then that means manually configuring wifi... which isn't ideal

I can't remove the default route... or modify it as freebsd blocks it

CCFL_Man: that's sad story, IIRC we were testing the OS upgrade and ended fine fine buils for FreeBSD 12 or 13 ?

ignore me, that's not the problem here

the common trick is for your vpn to push 0.0.0.0/1 where your default gateway is 0.0.0.0/0

in wireguard "PersistentKeepAlive " is important for clients behind NAT

it's nice to see you guys using FreeBSD and troubleshooting it, but it's getting late here, so Good Night

night mzar sleep well

daemon: wg-up uses 0.0.0.0/1 already

that is a narrower scope that your default gateway so should take priority

connect to the vpn and pastebin/pastee a netstat -rn

I rather not netstat as it contains my IPs :)

change them a bit so they are still sane but not yours

0.0.0.0/1 goes via wg0

192.168.2.0/24 goes via wlan0

192.168.2.0/24 needs to go via wg0 too

it sounds stupid but I cant do always on vpn if my laptop cant talk to my server properly

plus its to overlay WPA encryption on wifi... wireguard adds an extra layer to secure the carrier

I mean you could add a static route to it via your wifi/lan adapter

my router is also the vpn server :)

ah

but it needs to come in on the wg0 interface

but I dont see any way to set route priority on freebsd...

I know how to do this on linux...

this is solvable, but I would just get a cheap vps and make that the vpn master. Stick your nameservers, webserver and znc on it too; it just makes life easier

then all your devices are its client

lol

this problem will be solved when I stop doing a hairpin nat

will certainly help

though it really does sound like a routing issu

e

due to lack of money I stuck wifi and server on the same subnet... my new server is on a separate subnet

but the thing is though... the packets going via wifi... should still be wireguarded

I am using old APs... can I trust the WPA on them? no

WPA2?

yes...

but the APs are not security patched

and call home to tenda last I checked

block that on your gateway

I *could* buy new APs but that would landfill my current APs and also cost me money

daemon: issue is some wifi users dont want to use wg

I don't blame them

I want wg as an optional security improvement for my devices, and not affect other devices :)

on my phone this was simple, always on vpn setting on android will instantly do this for me

all packets will ALWAYS go via wireguard

so ... if you are disconnected from lan and wireless, and you connect lan and the connect to the vpn all is good, but if you then enable wireless and disconnect from the lan, then the route gets knackard?

daemon: no this has nothing to do with the route

if you are talking about the loss of network... if wireguard is started AFTER the link is up, it wireguard functions fine apart from the fact LAN packets dont get tunneled (which I want them to), if the link changes, or goes down and up... wireguard doesn't handshake again and ALL packets are dropped until wireguard is disabled (packets go via wlan0) or restarted (handshakes again and goes via

wg0)

polarian: why not use a separate subnet for your server/wg-accessible subnet and your lan?

if you have a decent wiwi adaptor you can make FBSD your AP. I did this a lonmg time ago until I needed N and no adaptors that FBSD had drivers for supported it... yeah lonmg time ago

(stupid keyboard cannot type/spell)

@lw, @rwp, @vortexx: I'm so sorry, my ADD is a mess and I got lost over here... I'm using "bmd" (github.com/yuichiro-naito/bmd) and since this is test/dev stuff (to see what 14.x brings) and all our physical hosts/jails use zfs I wanted zfs in here as well...

jmnbtslsQE: the server is on the same subnet as the wifi ap (unfortunately this will be fixed in the future) the wireguard interface has its own subnet, the router allows wireguard packets to enter the server/wifi subnet again, the reason for this is because the server is connected over ethernet (intercepting this would be difficult as you would need to be on site, however wifi encryption is not

I'm going to try UEFI and grub, whichever can get me a non-gui console like bhyveload does...

the most reliable, so as a little side hussle I was trying to set it up so that my laptop will tunnel all its packets to the router, and have the router pass the packets back into the subnet to the server... this then has the wireguard encryption ontop of the WPA for higher carrier security

different subnet, good idea. I typically use FBSD as routing firewall and turn off alll that on the AP so that means AP to your net goes through ipfw or whatever you want

problem is because dhcp advertises a /24 subnet, my laptop sees the servers directly, and the default firewall rule added by dhcp is matched to first, packets should go directly to the server and do not even need to go to the router... the solution would be to change it to /32 but then that means manually setting the IP

the ideal would be to set the wg0 link as priority... this means when wg0 is down the packets will pass freely through the normal route, but when its up ALL packets, including LAN, should be sent out via wg0

can DHCP be served by FBSD? (I do that)

hope that makes sense :)

???

I am not sure what you are getting at here, sorry...

then you can do what you want wit it

I think I'm using isc-dhcpd

shbrngdo: yes, you can run a dhcp daemon with freebsd

if my work was not married to M$ and demanded at least Ubuntu (so that they can install Intune and other assorted spyware), I would still happily run FreeBSD on my work machine. It was an Optiplex desktop where everything worked.

topcat001: run your ubuntu in a vm

if the wiwi talks to your net on 10.0.1/24 and everything else is 10.0.2/24, FBSD serves up 2 DHCP's, one for each assuming multi-homed. If not then yerah 1 adaptor 1 DHCP

🙃

nhot saying VLAN, nope, not going there

Actually I tried, and it was mostly fine, but the problem I had is that I needed to run Edge (yes I know) for Teams video meetings on Ubuntu (enforced), and that did not work reliably work in a vm rtprio

ah, that's a shame

I'm still not done with that; technically camera/audio passthrough should work. Perhaps it's my inexperience

Edge <3

can teams use chrome or is it too tied to winders... [

it can't because only Edge supports Intune/MDM auth

it's horrible, but much less horrible than being forced to run Win11 (that is truly horrible)

I love generally how snappy FBSD is. When hardware is good, it's really efficient.

figures. yet another reason. Winders is angeringg me a lot lately. Porting perfectly good Linux code ito winders application, and naturally it has firewall and driver issues tha I'm slowly fixing. No "howto" eithe, HOURS of plowing through docs for that one line of magic incantation code

shbrngdo: I think you are misunderstanding what I am looking for... I simply want FreeBSD to defaultly send all packets via wg0 route and not via wlan0 when wg0 is up

then to form the always on vpn I just block all traffic on wlan0 apart from wireguard

hmmm so the route prio on wg0 needs to be a smaller number

indeed, but I dont know how to work with poute prio on freebsd and I couldnt find anything in the handbook (unless im blind)

that was the issue I mentioned somewhere above :P

I don't think FBSD is measurably slower than Linux in my use cases; often faster. However, I'm splitting hairs here. Windows is typically much slower (because of $reason but I couldn't care less)

polarian: but the router is also on this subnet ?

hmmm I am confusing BSD's route with Linux it seems. Well maybe when the iface you want is available, maybe do a route change defauklt (et.)?

yeah, not sure if freebsd supports route metric

so far looks like no, unfortunately

polarian: i haven't used wireguard but not sure how it ever worked if you are routing the subnet (that includes the outer wireguard endpoint) via the wireguard interface (via its subnet/inner endpoint)

as far as i know, failing over to the non-wireguard would require manually changing the routes

or really, just adding/deleting the subnet from the wireguard interface, and ensuring the remote outer endpoint of the wireguard tunnel is still routed over the lan

much easier if you just change your subnets, even if it's just to split your 2.0/24 to a 2.0/25

hmm well i guess there is still some manual work involved in that case

jmnbtslsQE: it is on both subnets, yes

also this is not wireguard specific, this is a matter of the routing table

if you were doing ip forwarding it would be the same process

another nice trick to isolate an AP, use its WAN port to connect to your other subnet. subnet 1 on wifi, 2 on LAN, AP does dhcp for subnet 1, FBSD for subnet 2. just a thought

it sounds like a devd script would be enough to set your routes automatically when the wireguard tunnel goes up or down, but i haven't done much with devd

yes - devd event stuff. I have only used it to alter perms on USB devices but yeah it is powerful like that

also I have thought about adding/deleting the route, but freebsd doesn't allow you

well you set the gateway in rc.conf probably. you might wander through the /etc/rc.d scripts to see how they work

polarian: i've never seen that. what happens when you try?

not running as root? Just thought I'd ask...

it was as root

I cant remember though... not able to attempt rn

OK, i guess try again later and post here. i don't see any reason you cannot change the routes

@lw, @rwp, @vortexx: thanks to you all, and just a follow-up, doing a reinstall and using UEFI worked seamlessly, still a little curious about "bhyveloader" and why all these options are necessary compared to something like vmware...

spork_css: yw, glad you got it working

there's #bhyve btw for all things bhyve. I don't often hear of people using bhyveload, that was maybe the first way to boot anything when bhyve was developed, but now people just boot on UEFI

spork_css, Good deal! Glad to hear you have a good result.

I am fuzzy on this so take this with caution but I think, not sure but think, that instead of emulating the reset behavior of the machine completely that they skip over that part and jump right to loading the kernel and then jumping to it.

Normally an x86 system at reset jumps to FFFF:0000 (oh I know that's almost but not quite right, let me be fuzzy here) in 16-bit mode. It has 16 bytes of 16-bit opcodes available to execute there.

That is usually 16-bit machine opcodes to jump to a 256 byte block of 16-bit code. Which then traps to 32-bit or 64-bit native machine code. Which then loads the initial system loader. Which then loads the next phase of the boot.

That's all emulated exactly by KVM and VMware and all of the rest. But in bhyvve using bhyveloader I think they thought, why go through all of that messy stuff? We are running 64-bit native now. It's going to eventually be running 64-bit native. Let's just load the BSD kernel and jump there from here directly.

Not completely sure mind you but pretty sure this is what is happening with bhyveloader.

Meanwhile the uefi loader does emulate that all exactly. Which is why it's the generic way to boot random generic systems which can boot UEFI.

Now *I* don't like UEFI and if Legacy BIOS booting is available I will choose it. Which when using bhyve to boot Linux systems the grub method works well because it sets up a Legacy BIOS boot environment.

For VMs most of the time BIOS is sufficient

I only have a few Win11 testing vms (work requirement) on uefi

rwp: sounds about right, I got a little bit of a needed refresh on PC booting recently by watching far too many youtube videos from a guy that does retro-computing repairs