ugh, compiling llvm with -j1... this is gonna be a while

Soni: you got ipv4 disabled?

alepzi: not yet

Soni: i wonder how much ram usage is cut when ipv4 is disabled. and i wonder if ipv6 traffic is any faster

personally? it's not about ram, but about (code) maintenance. unfortunately upstream doesn't see it that way.

what did upstream say?

I've tried googling to no avail, is there somewhere I should check for issues with specific hardware? My X260 works great with both FreeBSD and GhostBSD out of the box, but my screen brightness keys don't seem to be detected. xev is not recognizing them when pressed.

zoid, I don't have one so I can't test, but have you tried the "PMU" "keys" combo described in the devd.conf manual page, devd.conf(5)?

just wrote my first rc.d script, w00t! it works, i can start/stop the service, but for some reasonputting myservice_enable="YES" in /etc/rc.conf doesn't seem to start it automatically. any gotchas? it's in a jail if that matters.

grats

I've not tried that yet! I'll give it a look.

markmcb, going for the easy guess: does your script use the "nojail" keyword?

no, just shutdown

OK. Then I guess it's time to share your script in a pastebin, suitably redacted if it contains confidential or sensitive info.

V_PauAmma_V: here you go bsd.to/a6Qu

Title: dpaste/a6Qu (Plain Text)

I just found this in the logs "listen tcp 10.0.1.231:20181: bind: can't assign requested address" ... but I don't get that error when staring manually ... is there a dependency I should list to avoid that?

When you start it manually, is that within the jail or outside?

inside the jail

What assigns 10.0.1.231 to the jail?

i think i solved it adding -r to the list of daemon args

If that makes the problem go away, that's probably because there's a timing issue associated with that IP address assignment.

the IP is assigned by the host as with an epair+vnet config

i tried "REQUIRE: NETWORKING" in the rc script, but that didn't help

i agree, seems like a timing issue

looks like it fails once and starts on the second try, so it's a very narrow miss on timing

OK. We've reached the end of my ability to troubleshoot jail networking issues. :-(

no worries, at least it's working :)

To figure out what caused it if you feel inclined that way, I would suggest 2 things: 1- doublecheck your jail configuration, and 2- wait until someone more knowledgeable than me looks in and answers.

So, it is okay to run the latest git of the ports on FreeBSD 14 release-p6 ?

SponiX: yes, ports is supported on all currently supported freebsd releases

there are no release-specific branches

thanks for the reply

I'm tinkering with FreeBSD 14 in a VM. If I get good enough with it, I might do it as my Host OS eventually

Soni: what do you mean by "upstream doesn't see it that way"? -- freebsd has full support for building without IPv4 code in the system. it sounds like your issue is you don't have enough disk space to build it, which isn't really an upstream issue

we have a -INET4 LINT kernel that gets built regularly so that the option to rip it out doesn't break it, and at least one developer that actively refuses to build with ipv4 included last I checked

LINT-NOINET

kevans: i had to submit 4 patches yesterday to get main to build without INET so it may not be 100% tested at all times :-)

mjg usually complains when it breaks because it breaks tinderbox

i wanted to fix ipfw too, but that's a bit awkward because it uses an AF_INET socket for the user/kernel interface

pretty quickly

I saw there is signal-desktop. Anyone know if there is a Discord package for FreeBSD?

SponiX: i saw this mentioned on fediverse github.com/SrWither/DiscordBSD

Title: GitHub - SrWither/DiscordBSD: an attempt at a native discord client for FreeBSD

livestradamus: thanks.. looks promising

iirc discord official policy is kinda dick-ish against unsanctioned clients, so maybe be careful there

kevans: Yeah, I've heard that as well

I might just end up running it within the browser and calling that close enough\

there isn't any real major advantages to having the electron client vs the browser anyway, from what I understand

Anyone running KDE Plasma 6?

SponiX: RE: electron app. Not for me since I can turn any URL into a launchable app

livestradamus: what method does that?

Can Chromium login with your Google account and sync passwords and so on? Like normal Chrome does (on Linux) ?

Is en-Googled-Chromium not available in The Ports?

is there a utility in the base system to format tabulated data nicely (in ASCII)?

I used to use cordless, It was a good client... either way, there's a telegram client on freebsd. its pretty good, even leaner than discord

lw: format? like column -t ?

nmz: yep, ty

people should use telegram more, the freebsd telegram channel for one is kinda empty, but there's people in it

the Foundation seems to have embraced Discord which is a bit disappointing, even though i understand it's probably because of the low barrier to entry

but... there's no application

for freebsd

I'm using it in chrome because gtkcord is lacking and uses a lot of resources

yeah, but the native 'app' is just the web app in an electron package anyway

not to mention you have to get the auth key from the browser and go into developer mode which is risky of termination of the user as well

lw: we believe freebsd would benefit from officially removing the ipv4 stack

Soni: that seems objectively false since many users still have only IPv4 connectivity. but from your point of view, how would that differ from simply compiling the system WITHOUT_INET?

lw: you don't have to break ipv4-only connectivity to go ipv6-only

since ppl are gonna run ipv6-only networks, then you need to maintain code to support setting up ipv6-only networks, in addition to maintaining an ipv4 stack. isn't that a waste of maintainer effort? you could instead do away with the ipv4 stack and support only the SIIT translation code, and that would be less code to maintain overall.

how is your FreeBSD router going to do SIIT when it doesn't have an IPv4 stack? you'd have to reimplement most of IPv4 inside ipfw or something to do the translation

Soni: but how would you then use freebsd if you have a ipv4-only network for some reason? (or just no ipv6 from your provider, so no internet without ipv4)

through "platd"

(a glorified raw socket that trivially translates ipv4 packets into the ipv6 world that ipv6-only freebsd can handle)

and that works with an ISP that only supports IPv4?

yes

so when dhclient gets an IPv4 address, what does it do with the address?

it's a bit awkward only having enough ipv6 to route the NAT64 prefix, but at least you'd only have a single ip stack, with all the benefits that comes with

dhclient would have to be integrated into "platd" - it needs to know when to attach/detach the NAT64 interface, and you can't send broadcast/multicast over NAT64

ok, and my Xyplex terminal server that only supports IPv4, how does that access the Internet through my IPv6-only router?

painfully

you also need to run a DHCPv4 server internally for devices like Google Chromecast that won't boot on an IPv6-only network, does platd handle that somehow?

Soni: "we believe freebsd would benefit from officially removing the ipv4 stack" This is a very delusional statement.

this would be a lot easier if there were a way to carry broadcast/multicast over nat64, as you could then just use a regular clat-in-libc with regular dhcpv4 tooling and whatnot

how does CLAT in libc help with IPv4-only hosts?

Every single server on the planet has IPv4, but far from all of them have IPv6. How are you supposed to interact with these servers in an immaginary "IPv6-only world"?

with SIIT

remiliascarlet: for servers it's actually pretty easy with 464XLAT (or SIIT or whatever). IPv4-only clients is the problem

a lot of widely-deployed devices, especially in IoT world, are still IPv4-only

"IPv4-only clients is the problem" Alright, good to know I'm the problem then.

? by 'the problem' i mean 'the problem with running an IPv6-only network', that wasn't some kind of personal attack

My ISP doas supply IPv6 addresses on request, except their request form is forever broken.

s/doas/does

"that wasn't some kind of personal attack" I know, I was just joking.

if i was the only user on our network, i'd have gone IPv6-only years ago, but i have to support other users and they bring their own devices they want to use, i can't really just tell them to spend £££ on new devices because i prefer IPv6

(that said, i did try IPv6-only for a while and it *did* work pretty well... it was mostly the Chromecast that had issues with it, i think we might replace that at some point and i'll try again)

doesn't help that our router vendor (mikrotik) still doesn't support NAT64, but i'm going to replace that with a freebsd box anyway

My previous ISP had a way to request IPv6 addresses, but you had to install something from either App Store or Play Store in order to request, so I thought "fuck that shit!".

honestly we only just set up ipv6-only at home, it'll be a while before we get more going with it

are you familiar with ipv6-mostly?

(dhcp option 108 etc)

you only just deployed IPv6-only network and you already know it would be easier for all FreeBSD users to immediately turn off IPv4? :-)

lw: given our initial experience setting this up, yeah

this was a pain to set up

luckily that was only the initial setup

but yeah, we should make this easier

i'm fine with making ipv6-only networks easier to set up, i'm sure any patches to do that would be appreciated. but that's a whole different thing from removing ipv4 support entirely, which will break things for many, many users

i've actually been meaning to look at making freebsd understand PREF64 in RAs for client-side CLAT setup, like macOS does

(macOS is basically the only mainstream OS that does IPv6-only properly today... Windows only does CLAT on LTE connections for some bizarre reason)

and even macos doesn't support pref64 (at least the last time I checked)

satanist: it does now, it'll configure CLAT automatically if it sees PREF64 in RA

at least since 13.x

ah nice, need to check soon if this allows to disable dns64 (makes problems)

another problem is, pref64 support in routers is not that common

yeah, freebsd rtadvd doesn't support advertising it, that's another thing i've been meaning to fix

hopefully that one should be pretty simple

need to fix if_bridge not loading on a non-INET kernel first

lw: so how can we remove ipv4 without breaking things for many users?

Soni: you can't, because those users depend on IPv4. you can argue they should upgrade to IPv6... sure, i don't disagree. but in real world it's not that simple

Soni: but if *you personally* want to remove IPv4 code from the OS, you can do that, by building WITHOUT_INET

lw: we mean from the kernel, we're not trying to drop ipv4 networks altogether

(not yet anyway)

well, you need to present a solution that works for current users, including users with IPv4-only hosts

(tho we are trying to push for more ipv6 networks)

if you want to create "ipv4d" that provides IPv4 connectivity for IPv4-only hosts by bridging to SIIT or something, you could do that

lw: we believe "platd" would work fine for most freebsd clients

the hard part is routers

you mean clat (client) not plat (provider)?

no, clat is in libc

in freebsd?

satanist: Soni wants FreeBSD libc to do CLAT internally to support IPv4 apps on an IPv6-only host. which is not an unreasonable suggestion, if they wanted to write the code for it...

of course that won't help things like Go that don't use libc, but hopefully there aren't many IPv4-only Go apps around

lw: hasn't go moved to using libc on the BSDs finally?

i do think it makes more sense to implement that in the kernel though, so it just works for everything

i recall seeing it mentioned somewhere

dstolfa: idk, i saw something about that but isn't it just for some syscalls?

(is this why we got libsys?)

no idea, i just saw it mentioned in passing. honestly i don't really care about go

I just don't get why "platd" would work fine for most freebsd clients, on the ipv6-only-client doesn't run a platd

i don't either really but sadly i do have to use some Go stuff, like prometheus

for clat it would be nice to have something like ifconfig bla -clat $ipv4-addr $source $prefix

satanist: i've never tested it, but ipfw does support CLAT already

while $source can also be a prefix and it would do some privacy-extention

satanist: what i was hoping to do with PREF64 was have the prefix show up in ifconfig and then auto-configure ipfw using that somehow

satanist: you don't need an ipv4 stack to put ipv4 packets on the wire

yes of course, but this way it would be quite easy to addopt

Soni: you kind of do, because whatever is sending IPv4 packets *is* your IPv4 stack

if you do it in userland, it's still an ipv4 stack

and could be used to route packegs for clients which doesn't support v6

lw: is a SIIT an ipv4 stack

Soni: every SIIT implementation i'm aware of uses an existing IPv4 stack, yes

lw: well this one wouldn't

what is "this one"?

if you're sending IPv4 packets and doing IPv4 NAT... that *is* an IPv4 stack

the "platd"/"ipv4d" thing or whatever we end up calling it

the fact it's in userland and doesn't depend on kernel IPv6 doesn't mean it's not an IPv4 stack

nah we don't do ipv4 NAT, we use the ipv6 stack for port mapping

i really hate code like this

if (PFIL_HOOKED_OUT(V_inet_pfil_head)

#ifdef INET6

|| PFIL_HOOKED_OUT(V_inet6_pfil_head)

#endif

) {

what's the least worst way to convert this to work without #ifdef INET? like i could add a temporary variable, but...

ifdef INET, if defined(INET) && defined(INET6), ifdef INET6?

i don't like that much duplication of code

i think this is the least worst option le-fay.org/tmp/30d/eokPZC.txt

this only duplicates the define checks, not the code

lw: could add a macro that does "false" in the case where INET6 is not defined, and the condition if it is?

hmm

e.g. defined a macro INET6_HOOK_CHECK(...) which does different things based on INET6 being defined or not. same thing for INET

if they're not defined, it just does false

and then you can undef them after you no longer need them i guess

if you don't want them to escape the scope

dstolfa: do you really think two macros is easier than my proposed fix above?

lw: no, but i'm fine with what's currently there too, even though it's a bit icky :D

i'm not too fussed about these things unless it's my own code tbh

dstolfa: the issue with what's currently there is it breaks on a non-INET kernel

link_elf_obj: symbol vnet_entry_inet_pfil_head undefined

linker_load_file: /boot/kernel.LFV6/if_bridge.ko - unsupported file type

right, then it needs to be fixed :D

lw: i don't have an opinion on which one is better. was just offering an option without a variable

yeah, sure

dstolfa: i didn't mean that as a criticism, i'm just really not sure what the best fix is :-)

i think i'll just send this version and see what reviewers say

lw: no worries, i don't take code discussions personally :D

it's just code

oh funny, i just found it already does this:

#ifdef INET6

#define PFIL_HOOKED_INET6 PFIL_HOOKED_IN(V_inet6_pfil_head)

#else

#define PFIL_HOOKED_INET6 false

#endif

it's just not used consistently, maybe i'll do it like that instead

(and add the INET version)

the fuck is this cgit.freebsd.org/src/tree/sys/net/if_bridge.c#n2647

Title: if_bridge.c « net « sys - src - FreeBSD source tree

don't write code like this :-(

uh oh... doesn't even seem to be a generator of any form, should just be a function probably

wow

dstolfa: i guess someone 'refactored' it to add bpf support and just turned the whole thing into a macro instead of doing it properly...

if_bridge patch (cc dstolfa): freebsd/freebsd-src #1159 ... tested to the extent that i can load if_bridge.ko and create a bridge

Title: sys/net/if_bridge: support non-INET kernels by llfw · Pull Request #1159 · freebsd/freebsd-src · GitHub

actually this is wrong because i mixed out HOOKED_IN and HOOKED_OUT

better patch up

jbo: any idea what's going on this this, i need to build it on arm64... if it's not likely to be committed i'll have to fork a local ports tree to include it bugs.freebsd.org/bugzilla/show_bug.cgi?id=276996

Title: 276996 – [NEW PORT] databases/postgres_exporter: PostgreSQL metric exporter for Prometheus

lw: stuff like cgit.freebsd.org/src/tree/sys/net/if_bridge.c#n2647 is why i'd never participate in open source C :)

Title: if_bridge.c « net « sys - src - FreeBSD source tree

SKull: yeah it made me o_O a bit but i'm sure other OSs have just as worse code...

writing my own OS from scratch is on my todo list but that might take a while

hey, do freebsd 14 has something i need to set, for me to be able to use /etc/jail.conf.d/jailname.conf as placeholder for jails? atm it only accepts /etc/jail.conf and wont see the conf i placed in jail.conf.d

Who's in the Bay Area?

CrtxReavr: Californians

what's the company called that does FreeBSD stuff and begins with a 'k'? i thought it was Klara but that's some kind of credit provider

What do they sell?

i don't know, like... zfs stuff? or something?

oh, it is Klara

are there two companies with the same name?

Stranger things have happened.

lw: klarasystems.com

Title: Klara Inc | Open Source Development. Reimagined.

the other one you probably refer to is Klarna (.com)

ah right, the bnpl company is klarna

yeah, the linkedin people page reads like it's grown a good bit

AllanJude: which of the eight open positions has the highest priority for you at the moment?

probably the technical project manager, and then the com-rel role

so i just solved a problem i've been having with tmux. the default terminal "e.g., echo $TERM" is tmux-256color in tmux, but FreeBSD doesn't know what that is without terminfo-db installed. should that package be a dependency? i was breaking mouse functionality for me in tmux. not sure how i suggest a change.

I'd e-mail the tmux maintainer

will do

markmcb: yeah, I believe that's the best way (though tmux-256color seems to be in termcap on recent versions)

kevans: when you say recent, do you mean 14p.0p6, or something newer in stable/current? i'm on 14.0p6

current

maybe stable, haven't checked

Yet another reason why I stick to screen.

markmcb, I have tmux-256color in termcap in 13.2R okay. Perhaps the problem is that the termcap entry needs expansion to include a capability that is included in terminfo but not in termcap.

That would be the better solution. Improve the native termcap database.

rwp: maybe so, i'm not so well-versed in this stuff. whatever is missing breaks the tmux "send-keys -M" functionality to pass mouse events to apps in a tmux pane. i'm not sure what/where i'd report.

docs.freebsd.org/en/books/handbook/jails/#creating-vnet-jail in the "ADD TO bridge INTERFACE" part of the sample jail config, where do i set 'private' on the epair#a interface?

Title: Chapter 17. Jails and Containers | FreeBSD Documentation Portal

What's the best way to check if a CVE is handled by a freebsd security advisory?

The list of SAs on freebsd.org is not helpful if all I've got is a CVE ..

it seems optional to copy /etc/localtime into a jail so why do docs imply it's necessary?

Ltning, If you subscribe or download the freebsd.org/security/advisories mailbox then you can search the advisories for the CVE number and see what it says. Easier is the source. If you have the git source then you can search the git source for the CVE number.

Title: FreeBSD Security Advisories | The FreeBSD Project

do we need to worry about calcru: runtime went backwards

Soni: it's an issue with the CPU speed, usually called by Intel Speedstep.

Do you have powerd(xx)? running?

no idea, this is a VM

it kinda crashed for a bit (it paused because we ran out of host disk)

Then it's not registering itself properly as a VM, cf. cgit.freebsd.org/src/tree/sys/kern/kern_resource.c#n1018

Title: kern_resource.c « kern « sys - src - FreeBSD source tree

I'm specifically going off of cgit.freebsd.org/src/commit/sys/kern/kern_resource.c?id=bacb140f31a in making that guess, because otherwise your CPU is probably very fucked.

Title: src - FreeBSD source tree

Ltning: marc.info/?l=freebsd-security-notifications&r=1&w=2

Title: MARC: Mailing list ARChives

that'll search in the bodies of the mails sent to the security-notifications mailing list

rwp, debdrup: Yea, I got about that far myself, but it has just came to my attention that a reverse search (cve -> advisory) could make certain peoples jobs a lot easier. I can figure it out, but those people that receive "security testing reports" and need to respond don't necessarily want to search mailing lists or source code.

The nearest I got was vuxml, and for the time being the website can list all SAs by CVE, but that's inefficient and not scalable..

Ltning: problem is, CVE isn't a universal identifier

(Then again, several of the public CVE databases link back to the advisories - but not always)

I mean, the real answer is that Someone(TM) uses AsciiDoc and/or the ruby scripting it offers to add the CVES from any .asc file that contains it.

Right now the openssh stuff from december or so is causing a fair bit of noise

Because a scan doesn't reveal that systems are update

+d