dstolfa: you around?

[tj] (from a few days ago) I'm doing what's in the wiki but bhyve aborts immediately: Unable to setup memory (17)

I'm trying to pass through a pie USB card

pcie

does your computer support VT-d?

crb: acpidump -t | grep DMAR

I think so it's a 5950x, that's relatively recent risen 9

Maybe I don't have it turned on in BIOS since that command give nothing

yeah, unboot the machine, go into the bios, and check that it's got the IOMMU (AMD-Vi I believe it's called) enabled (it won't be called VT-d as it is AMD)

OK I'll have to give that try next time I can reboot it

thank you!

put it in your handwritten journal if that will be more than a few days

crb: you need amdvi enabled on 14, something has occured on current I haven't figured out yet

this is covered in the pcie passthrough wiki page

I had an issue where ppt was loading far too far behind xhci so it couldn't take the controller, but I don't know if that is on 14 or not

OK I did not have IOMMU turned on, it's on now

but ....bhyve: PCI device at 8/0/0 is not using the ppt(4) driver

Device emulation initialization error: No such file or directory

you can try: devctl detach pci0:8:0:0

devctl set driver pci0:8:0:0 ppt

still Unable to setup memory (17)

pciconf -l | grep ppt

devctl: Failed to set pci0:8:0:0 driver to ppt: No such file or directory

devctl: Failed to set pci0:8:0:0 driver to ppt: No such file or directory

I don't think you can attach the ppt driver if there's already another driver assigned (i.e. not "none")

but I can be entirely wrong

devctl detach pci0:8:0:0

that is why you need to detach it first

you might need to correct the pci path

true

iltisadl

pretty sure that is the correct path and I did detach it first

what is attached to it right now?

what is in pciconf?

none1@pci0:8:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x1912 device=0x0015 subvendor=0xffff subdevice=0xffff

is vmm loaded?

what freebsd?

FreeBSD eclipse.ChrisBowman.com 14.2-RELEASE FreeBSD 14.2-RELEASE releng/14.2-n269506-c8918d6c7412 GENERIC amd64

22 1 0xffffffff83400000 33e438 vmm.ko

you could try adding 8/0/0 to ppt devs and rebooting

not familiar with that, how do I do that?

so I have this: pptdevs="8/0/0" in /boot/loader.conf I reboot and pciconf -l | grep pci0:8:0:0 shows:

xhci0@pci0:8:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x1912 device=0x0015 subvendor=0xffff subdevice=0xffff

none2@pci0:18:0:0: class=0x130000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1485 subvendor=0x1022 subdevice=0x1485

you can try detaching xhci and reattaching: devctl detach xhci0

devctl set driver pci0:8:0:0, but it might not work again

ok now xhci0@pci0:8:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x1912 device=0x0015 subvendor=0xffff subdevice=0xffff

none2@pci0:18:0:0: class=0x130000 rev=0x00 hdr=0x00 vendor=0x1022 device=0x1485 subvendor=0x1022 subdevice=0x1485

ok now: ppt0@pci0:8:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x1912 device=0x0015 subvendor=0xffff subdevice=0xffff

but still Unable to setup memory (17)

jbo: i am now

jpb: ^ wrong ping

:o

hello there, anyone fancy committing this patch for support for 2 sitecom wlan adapters? paste.debian.net/plain/1366657

racoon: nice patch, please submit it via bugzilla

will do, have requested an account

OK

racoon: reviews.freebsd.org/D49588

racoon: please tell me who you are so I can set the author line in a commit

has anyone been able to get intel discrete graphics cards working on FreeBSD?

I've tried i915 from drm-66-kmod on 15-CURRENT, but it just panics on loading the module

does the card work on linux 6.6?

yes

but the relevant issues on drm-kmod github page don't look promising

just tried the 6.8 version here freebsd/drm-kmod #344

same thing, panics when loaded

mtll: was the drm-66-kmod package built in place using up-to-date sources ?

yeah I built it from the ports tree

freebsd is CURRENT, installed literally today

OK, there are cgit.freebsd.org/src/commit/?id=f33…9797374d135b64da59e0ef533ac69d0a5b7 and cgit.freebsd.org/src/commit/?id=0b0…fb9488a3ac6b75836ca9cee8227b9d4b54c, but I don't know how relevant they are

mzar: yeah, might be relevant, probably included in the custom kernel I built for the 6.8 DRM branch though

it was straight from dumbbell's github anyway

dstolfa: may i dm?

jpb: sure thing

Hi there, quick question: the datasets I create on top of a pool = are they going to consume from the total pool available size?

sure, they will

As much as I love the 'offline' build feature of the ports tree (I know you can turn that off, but I'm talking about 'official' pkg build), language based package managers don't show any signs of going away. Considering how security is a big deal these days,

I find it ironic that this is common place/generally accepted practice. What's FreeBSD's latest stance on this? Will they begin to allow the building of official packages to work with things like npm, yarn, gem, gradle, maven, composer, etc...?

still haven't, no

golang notably wants to do similar, but we instead ended up with some tooling to generate the required dependency list to download

It's great option, very simple and effective (when it works). I wish we'd have similiar tooling for the other ones. I tried making one for composer, but got stuck on some issue where composer wouldn't allow me to see what it wants to download.

That's the problem, a lot of these package managers don't like it when you try to force them offline

...And the upstream devs are unwilling to help.

there's going to be very aggressive opposition if you try to enforce ports tree full build to depend on online connectivity and having it bring outside data/parameters in dynamically

and I mean violently aggressive, because it's a hideously bad idea

Yeah, which is why I find the practice by every Linux distro out there so ironic.

I guess there are benefits in being in a company where doing nothing is already a success story

tuaris: yeah, the mix of download/build by 1 tool and sometimes even 1 command is really frustrating

i really hope "panic: tcp_do_segment: sent too much" gets fixed soon, i've been putting off upgrading just in case

it was fixed IIRC

mzar: maybe not as someone just reported running into it on latest current

ah.. so they will work with packet drill... hard work

ivy: I've switched to the rack stack locally until tuexen gets a chance to analyze the pcap from my report

kevans: ah, is rack not affected?

same here, I am on RACK since it showed up in 13

ivy: yeah, tcp_do_segment is specifically the default stack implementation; rack has its own implementation

RACK always worked for me like hell

my historical position has been to just keep with the default stack barring some compelling reason to switch; I just don't understand the scenarios where I'd benefit from RACK well enough to make the informed decision to move to it full-time (and the default stack has filled my needs to the best of my knowledge)

now, panicking once or twice a day especially when I'm about to host a meeting is a compellingr eason

kevans: i heard RACK might become the default at some point so i guess switching now isn't so bad anyway :-)

after RACK gained TCP-MD5 support it became 100% comprehensive stack, we are not using it on the routers though

mzar: are you still deploying TCP MD5? i thought it had been obsoleted by TTL security

obsoleted by TCP-AO, but it is implemented in neither of our TCP stacks

FreeBSD is mostly business-driven project, we need more ISP businesses here hiring programmers and upstreaming changes

i'm curious what tcp-md5 protects against that ttl security doesn't

at least all ISPs in finland are completely retarded, no chance they'd contribute anything :(

RST

mzar: why doesn't ttl security protect against rst?

i mean, protecting against forge RST is basically the entire purpose of ttl security, aiui

it recognises only TTL

that's sad story Koston

yes, but RST packets have a TTL, don't they?

it's imminent part of the IP header

mzar, it really is unfortunate. the fiber network here is very good, but that's the extent of what ISPs comprehend as good business

right, so ttl security will drop forged RST packets

because the ttl will be too low

i'm not saying you shouldn't use tcp-md5 if you want, i've just never heard that ttl security can't protect against this

at least you have FTTH, in some countries ISPs are only charging for cooper and changing voltage/current/modulation to maximise profits

true, I know it's even worse in most places

ISPs are just owned by old af geezers who are interested in nothing but their retirement bank account

this is a nice patch, I tried to attract some people to it, but they are busy, if you guys have PCs and IPv6 on them, maybe want to try and give feedback here bugs.freebsd.org/bugzilla/show_bug.cgi?id=245103

it needs more testing, and comments from people familiar with EPOCH and VNET contextes which probably should be added here

does it apply on rel branches or only -current?

I have it on stable/14 too, so should apply on 14.2

ok cool, then I can give it a spin, just need to consolidate a few services to free up a box for testing

mzar: thanks.

Lets say I have a spare disk (not the system/boot) that I am enabling gely encryption - single partition, full size. I want to create a zps pool with that disk. I first gely attach (password prompted) and then add to pool.

once a boot, I will manually gely attach again and type password. How do I make zfs recognize that disk.eli is available and auto mount?

geom will taste it

mzar: I (no doubt) did something wrong. Cause geom is not identifying it. I am certain that I am doing it wrongly.

cybercrypto: I could be wrong, I am sorry

mzar: nope, I am learning. since this is 'sandbox disk' I will redo step by step again... my goal is simple= I want a 'zfs-pool-my-data' running in a disk, that disk is previoulsy gpt partioned + gely.

do it step by step, take notes, prepare script and you will be fine

mzar: sure, that will help me understanding where is the possible missing step. thanks

what is the name of the feature for AMD VT-d/IOMMU?

crb: VT-d doesn't exist on AMD, and AMD IOMMU support isn't indicated in cpuid as far as i know, so there's no feature flag for it

ivy, that's what I wanted to know, thank you

so is there a way I can tell if freebsd see that feature as turned on?

crb: i believe you will see an ivhd device in dmesg, or you can check for "options IOMMU" in the kernel config

I *guess* that amd-vi is implemented after a certain point on all their kit, hence lack of a feature associated with certain firmwares

duncan: no, it's just not in cpuid, there's another way to check for it via ACPI. see amd.com/content/dam/amd/en/document…docs/specifications/48882_IOMMU.pdf §5.2

AllanJude: you around?

Ok I assume if I have a wireguard configured on my laptop, split tunneling is a bad idea, and seen as wg-quick redirects ALL traffic through wg interface (apart from traffic to the WG peer) this would not be possible without writing the routing table rules manually. So I assume the better approach would be to delve into rdomain's?

I remember some discussions on it within the OpenBSD mailing list (I am aware the rdomain implementations differ)

have the default rdomain for everything to go via the VPN, and then something you need to be outside of the tunnel (for example local traffic, you can use a second rdomain

any other suggestions?

wg-quick does not redirect all traffic, just what's specified in the allowedIPs right?

it's not manual at all

hm, what is your desired network layout? I don't fully understand that

yes, wg-quick creates routing rules for whatever is in AllowedIPs

'split tunneling is a bad idea' is maybe a bad premise to start with, it depends on what you're trying to accomplish with the tunnel

rtprio: yes it does, it adds a rule for 0.0.0.0/1 via wg0

ohh right its from AllowedIPs

duh I am silly

I completely forgot it existed

could just exempt local subnets from it

kevans: always on vpn

in which case you want no split tunnelling, not even for local traffic

the very concept is to harden wifi, as WPA is not the strongest

....

with wireguard you have 3 layers of encryption on a packet payload, TLS, then WPA ontop of the packet, and then Wireguard on top of that

but sometimes, and only sometimes, say you want to configure a new device, without configuration you got to drop the wireguard tunnel (I have pf drop all packets to anything other than the wg endpoint)

wpa3 is plenty strong enough

rtprio: and unless you are running latest APs, you wont be that lucky

i am that lucky

and lets not forget, in most peoples cases you are trusting a black box

unless you are running openwrt

which I wish I could but my APs are too old and too shit

and that doesn't protect you on public wifi, in a lot of cases do not use any encryption

Always-on-VPN should be something you set up and leave...

also there is another problem, captive portals, something I haven't delved into yet

my attempt is very basic and incomplete...

i pity the intern that has to set up wireguard on everyones pc

polarian: right, but that kind of setup isn't necessarily implied by 'running wireguard'

kevans: sorry for being ambiguous

rtprio: this is a home setup, not for a business... a business would not want all traffic going via their network, their employees youtube browsing will cost them a fortune in bandwidth. From what I have heard the majority of businesses split tunnel, secure access to the companies network while out of office, but not pushing the users normal traffic via the tunnel and congesting the companies

network.

is it extreme? sure

if it's a home setup, how hard is it to update your ap, jfc

but it also protects against common attacks, such as DNS spoofing... cant spoof DNS which is only provided via a trusted recursive resolver over a wg tunnel + DNSSEC validated

rtprio: I am stubborn and do not wish to throw away working hardware

polarian: my dad says the same thing about his windows 2000 systme

rtprio: I am running a E6430

right now

who all are you letting on your homenetwork who's spoofing dns

might not be as old, but it is still old

but it works, why replace it?

rtprio: this is my laptop, I travel with it

because it doesn't support modern cryptogaphy, or receive regular updates

(not sure if you can really call any internet connected device "working hardware")

I mainly hotspot because of the damn captive portals

I assume learning rdomains would be a good idea

ok man, good luck to you

my question was kinda answered though, I forgot the routes were added from AllowedIPs

so thanks for the correction :)