01:56:09 <mns> I created my vnet jail based on https://docs.freebsd.org/en/books/handbook/jails/ and networking was working, uptil Oct 30th.  Now though, I can't reach out the internet from inside the jail,  nor can I reach the jail fromthe outside.  I can't even ping the jali's gateway from inside the jail.  No configuration changes have been made, I've verified that.
01:57:28 <mns> I did do an upgrade to 14.1-RELEASE-p6, which I don't think should matter as its not a kernel upgrade.
01:57:38 <mns> Any thoughts or suggestions?
01:59:03 <rwp> I hear "No configuration changes been made, I've verified that" and I must laugh because everyone *always* says that! :-)
01:59:42 <rwp> If you have snapshots you can diff between to verify by the way.  And if it really is the patch upgrade you could use Boot Environments to boot the previous and it should work if that is the change that broke something.
02:00:17 <rwp> Meanwhile...  Double check /etc/pf.conf and enure it is set up everywhere it is needed.
02:00:53 <mns> rwp: yeah I know, that's why I mentioned that *after* checking.  :-)
02:01:03 <rwp> And of course /etc/jail.conf and /etc/rc.conf with cloned_interfaces and ifconfig_bridge0 type configuration is the critical points.
02:03:16 <mns> I have /etc/pf.conf setup on the host.  I've verified the /etc/jail.conf and /etc/rc.conf, with teh bridge0 and epairs as well.
02:04:09 <rwp> I am running 14.1-RELEASE-p5 kernel and 14.1-RELEASE-p6 userland and things work here with that combination.
02:04:41 <mns> I've run netstat -rn inside the jail but the gateway entry doesn't seem right to me, as it shows epair151 for the interface, and I was expecting epari151b as the interface
02:05:50 <rwp> However my jails are in need of upgrade.  I haven't gottenaroundtuit yet.  And I can't pfctl -sr or it coredumps due to the mismatch.  Which is annoying.
02:06:24 <mns> pfctl inside the jail or outside?
02:07:18 <rwp> One of my vnet jails is a router for other jails on a labbench network setup and needs to have routing set up inside.
02:08:06 <mns> yours sounds complicated,  mine is just a simple, straightforward web server, using the vnet example in the Handbook
02:08:07 <rwp> My jails show my epair ja0 without the a and ja0a is a member of bridge0 leaving ja0 to be attached to the jail.
02:08:56 <mns> ok so the netstat output is correct in that case, comapred to yours
02:09:47 <rwp> Yours is a vnet jail?  On the host side "ifconfig bridge0" (use your bridge name) should show the 'a' epair as a member of it.  (I think the ends can be swapped symmetrically.  What's in a name?)
02:10:22 <rwp> And it should also show your network device.  And if that is your only network device then your IP should be associated on the bridge.
02:10:59 <rwp> (I am running mine on a multi-NIC system so I attach the bridge to the secondary NIC and don't assign any address there.)
02:11:17 <rwp> Oops.  I looked at the time and I must run off.  Sorry.  Good luck!
02:11:26 <mns> yeah I see the epair151a as a member of my bridge (jail0)
02:11:41 <mns> I have a single interface, bge0
02:11:57 <mns> thanks, no problem
02:13:14 <mns> hmm I don't see any ip for epair151a
02:14:35 <Jeanne-Kamikaze> Where do people get their /usr/ports from, bsdinstall, or a git clone post-installation? The handbook seems a bit ambivalent as to which is the preferred approach.
02:16:04 <mns> Jeanne-Kamikaze: I get mine via git
02:21:35 <Jeanne-Kamikaze> Is that preferred for development these days? And is it OK to yank an existing /usr/ports in CURRENT and replace it with a git clone?
03:17:16 <HER> Jeanne-Kamikaze: porstnap fetch extract iirc
03:18:12 <HER> Jeanne-Kamikaze: https://forums.freebsd.org/threads/new-install-and-run-portsnap-fetch-extract-update.33744/#post-185970
03:20:05 <Jeanne-Kamikaze> Thanks
03:21:27 <HER> Jeanne-Kamikaze: also you should consider using poudriere to build ports
03:23:37 <Jeanne-Kamikaze> Is that mostly to guarantee that stuff works on a clean state? I'm a noob, just working through the handbooks right now. (I also seem to have run into a kernel panic with amdgpu on a current gen AMD GPU.)
03:28:07 <HER> Jeanne-Kamikaze: there is nothing wrong if you want to build ports locally from /usr/ports . Also you can probably skip that and use the binary ports from pkg that should work just fine and you wont need to build anything
03:29:25 <HER> Jeanne-Kamikaze: and with poudriere, it can run inside a jail and build the ports you want and then you can re-use them in other machine. Since you are learning, you probably dont need to configure poudriere now.. but maybe in the future you might consider it
03:29:35 <HER> Jeanne-Kamikaze: i would just install using pkg
03:30:23 <HER> pkg update ; pkg search firefox ; pkg install xorg i3wm firefox ...
03:30:41 <Jeanne-Kamikaze> I'm going to start with that, thanks.
03:33:01 <HER> if you want to build, no problem, but it might take very long =p and once you run a "make install", you will get multiple config screens after each port is built. its possible to run all the recursive configs with the command "make config-recursive"
03:33:08 <HER> Jeanne-Kamikaze: yeah just go with pkg
03:33:35 <HER> also, dont mix pkg with port
03:33:54 <HER> thats not reacommended
03:35:15 <Jeanne-Kamikaze> How do you go about to contributing to a random piece of userland software? Do you pkg install most things except for that one, which you build/modify from ports?
03:36:28 <HER> Jeanne-Kamikaze: also, since you got some kernel panic, it should work.. but you may also test with the https://nomadbsd.org/screenshots.html
03:37:00 <HER> nomad should figure out the graphics setttings and even if you dont install it, you can see if it autodetects everything
03:37:07 <HER> ghostbsd is also similar
03:37:50 <HER> Jeanne-Kamikaze: well you can do that yes.. but thats not recommended.
03:38:42 <HER> Jeanne-Kamikaze: also use ZFS if you can, that way you can always create a snapshot before you do anything... and rollback if needed
03:48:55 <Jeanne-Kamikaze> Thanks. Yeah, ZFS is the default now in bsdinstall.
04:36:54 <mns> ˜/quit
08:10:37 <vxwarlock> https://www.freebsd.org/commercial/software_bycat/
08:11:19 <vxwarlock> There are broken links on this page, can you please check them?
08:13:15 <vxwarlock>  Malicious people can take this address and create a link to themselves using your address.
08:41:21 <sopparus> anyone got samba4 to work after win11 24h2?
11:54:27 <polarian> brought this up many times, but yet to find a solution. so my home server and vpn server is on the same network (same public IP), wg-quick will set a path that the path for the physical interface is the public IP of the wireguard server, all other packets will then pass through wg interface which is then passed to the physical interface, however when i connect to my server which is a different
11:54:29 <polarian> host behind the same router as the wireguard server it wont pass thorugh the wireguard tunnel and is leaked, which isn't a big deal apart from the metadata and less encryption on it, but some networks allow VPNs but block ports, plus I can't block public IP addresses accessing things on my server and mandate it through the tunnel if I cant tunnel
11:54:49 <polarian> I can't change the route for the physical interface, freebsd wont let you remove default routes
11:55:05 <polarian> besides it would break the tunnel
11:55:24 <polarian> any suggestions on how to force the packets through wg
11:55:48 <polarian> if I add a route to wg which is higher priority it would loop, wg --> wg --> wg --> wg surely...
12:56:09 <rtprio> you can remove the default route but you would be dissapointed
12:56:22 <rtprio> polarian: are both servers on nat?
13:12:21 <DarkUranium> Any vm_bhyve users here? I can't for the life of me get networking working on the guest.
13:13:53 <rtprio> DarkUranium: what's up
13:14:41 <DarkUranium> Just starting with vm_bhyve (or bhyve in general) for the first time ever. I can't quite figure out why, but my (Alpine Linux) guest can't seem to be able to connect to the network. The vm_bhyve thing is setup as per instructions on GitHub, etc.
13:15:15 <rtprio> what switches/bridges did you set up? either via rc.conf or vm-bhyve?
13:15:50 <DarkUranium> I do have appjail on the same system, which might admittedly be interfering (tl;dr I'm trying out both)
13:16:15 <DarkUranium> The only bridge I can see is the `vm-public` one from vm_bhyve. Connected to my external IF, renamed to `jext`.
13:16:20 <DarkUranium> Well, "switch".
13:16:33 <DarkUranium> I can paste all of ifconfig in a pastebin if desired, it's quite lengthy.
13:18:14 <rtprio> does vm-public have the tun that corisponds to the alpine guest as well as your functioning host interface
13:18:31 <DarkUranium> You mean tap, or?
13:18:38 <rtprio> yes
13:20:04 <DarkUranium> It connects to tap1 when the VM starts, but I'm not 100% sure where to check what the VM itself is attached to.
13:20:14 <rtprio> there should be a note in the interface
13:20:34 <rtprio> er, description
13:20:45 <rtprio> tap13: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: vmnet/pihole/0/public
13:20:46 <DarkUranium> "Opened by PID 15671"? Does appear to match the VM, yes.
13:21:09 <DarkUranium> `vmnet/docmost/0/public` seems about right, so yeah, it appears connected
13:21:17 <DarkUranium> (`docmost` is my VM name)
13:21:22 <rtprio> yep
13:21:42 <rtprio> what is the ip of the host and what is the ip of the docmost?
13:22:26 <DarkUranium> Docmost doesn't have an IP (since it can't seem to reach anything). Host is 192.168.1.8.
13:22:53 <DarkUranium> BTW, tap1 mac address doesn't correspond to that of docmost. Not sure if that's correct or not, just an observation.
13:23:19 <Alver> ... well, if it doesn't have an IP, not being able to reach anything is kind of expected. Or did you want to run DHCP?
13:23:33 <DarkUranium> Basically, from the VM, I just get: `ping: sendto: Network unreachable` if I try to ping anything (even localhost)
13:23:52 <DarkUranium> I mean, I know. I did try DHCP, I also tried assigning it an IP, but the assigned one didn't want to show up outside.
13:23:55 <DarkUranium> I'd prefer DHCP, though.
13:24:27 <DarkUranium> I can try a manual IP for now, since that's simpler (but it didn't help much last time --- I've recreated the VM since, during debugging)
13:24:42 <rtprio> that shouldn't be necessary
13:25:17 <rtprio> appjail? https://github.com/DtxdF/AppJail ? running on the host?
13:25:33 <DarkUranium> Correct. Like I said, I was trying out both. I am well-aware that the issues might be because of some network config conflict.
13:25:50 <DarkUranium> (on an unrelated note, do you know of any SW other than CBSD that can handle both jails and bhyve?)
13:26:45 <rtprio> IIRC that's the only one. i wasn't super keen so i keep using vm-bhyve
13:27:11 <DarkUranium> Yeah, same.
13:27:27 <DarkUranium> I've been tempted to try out SmartOS, TBH.
13:27:33 <DarkUranium> It does both, but it's Solaris-based, not BSD.
13:27:42 <DarkUranium> ANYWAY, this is my networking mess: http://vpaste.net/73Zde
13:27:49 <DarkUranium> jext is the external IF. em0 is unused.
13:28:00 <DarkUranium> jext is a renamed wlan0 if it matters.
13:28:26 <DarkUranium> In there, vm-public is vm_bhyve's switch and tap1 is the VM.
13:28:56 <rtprio> not sure how the appjail could be interferring, but there is a lot going on there
13:29:42 <DarkUranium> Same, I don't think it should be, but ...
13:29:51 <rtprio> are you at all familar with tcpdump ?
13:30:15 <DarkUranium> Not very. I think I might have briefly used it aeons ago.
13:30:32 <DarkUranium> FWIW, I did check all the usual suspects like net.inet.ip.forwarding being enabled.
13:30:35 <rtprio> console into your vm, and give it an ip
13:31:41 <DarkUranium> Done.
13:32:07 <rtprio> from your host, `tcpdump -ni vm-public `
13:34:53 <DarkUranium> Done. There's a lot of traffic, mostly from the PC I'm sshing from.
13:36:02 <rtprio> add a `port \! 22` will help with the ssh
13:36:54 <DarkUranium> Was actually 54915 UDP, so maybe not that. Either way filter it, thanks.
13:37:05 <DarkUranium> filtered*
13:37:25 <DarkUranium> Note that now that I've assigned an IP manually, I can ping the host from the VM (and nothing else), and the VM from the host.
13:37:59 <rtprio> it's a start
13:38:32 <rtprio> ok, from the guest, try a uh, `fetch https://freeebsd.org`
13:39:46 <rtprio> er, that might not work since you'll see dns probably try to work and fail
13:39:51 <rtprio> but you should see some packets from it
13:39:57 <DarkUranium> Yeah, these: 14:39:44.030596 ARP, Request who-has 192.168.1.1 tell 192.168.1.9, length 28
13:40:02 <DarkUranium> (also, s/fetch/wget/ because Linux)
13:40:57 <rtprio> oh right, i forgot
13:42:30 <rtprio> but no arp reply
13:42:36 <rtprio> ?
13:43:37 <DarkUranium> Doesn't look like it, no.
13:43:40 <DarkUranium> Sorry, multitasking.
13:43:50 <DarkUranium> (something high-prio came up)
13:43:55 <rtprio> no worriew
13:51:34 <DarkUranium> Yeah yeah, no reply. Just those messages.
13:52:10 <rtprio> tbh i don't know how bridging would work on wifi
13:59:47 <DarkUranium> rtprio, shouldn't it be the same as non-?
14:00:39 <rtprio> well, maybe
14:00:58 <rtprio> now, if you can; tcpdump the wireless instead of the bridge  and try a wget again
14:07:32 <DarkUranium> 15:07:13.322484 ARP, Request who-has 192.168.1.1 tell 192.168.1.9, length 28
14:07:35 <DarkUranium> So basically, samer thing.
14:07:43 <DarkUranium> s/r / /
14:07:43 <rtprio> never a response?
14:07:45 <DarkUranium> Nope.
14:08:19 <DarkUranium> It feels as if the router isn't liking the (virtual) machine, for some reason.
14:08:40 <rtprio> is it a consumer router, or can you tcpdump on it as well?
14:09:42 <DarkUranium> Alas, consumer. I never brought the "proper" one over since I moved apartments.
14:10:03 <DarkUranium> I generally rent servers, but for tests and such, I tend to do them at home, heh.
14:11:15 <DarkUranium> I do have access to the router's ARP table, and the .9 doesn't show up there. Not sure if it's because of the static IP or not.
14:11:23 <DarkUranium> (.9 == VM)
14:11:30 <rtprio> it would still need to look it up, static or not
14:12:09 <DarkUranium> I know. But maybe it's not showing the full table, is what I mean.
14:12:30 <DarkUranium> I'm beginning to suspect some sort of a firewall issue on the host system. I do have pf running.
14:12:41 <rtprio> ...  uh yeah
14:12:52 <rtprio> that could impact things
14:13:21 <Alver> Quite. :D
14:13:45 <DarkUranium> Yeah, appjail depends on pf running, so :P
14:13:57 <DarkUranium> Sorry, I forgot to mention it because I thought it was a given when I mentioned appjail ^^
14:14:00 <DarkUranium> Forgot y'all might not be familiar.
14:14:06 <rtprio> i don't know/use appjail
14:14:29 <rtprio> well, then you're going to have to figure out how to extend the pf.conf from appjail to permit your VMs access
14:16:11 <rtprio> or try it without appjail /pf to get the feel for things
14:17:07 <DarkUranium> pfctl -s all: http://vpaste.net/QvJOx
14:17:22 <DarkUranium> Yeah, might be a good idea to just disable pf for now.
14:17:42 <rtprio> i haven't had enough coffee to diagnose someone elses pf.conf
14:17:53 <DarkUranium> lol fair
14:18:10 <DarkUranium> It's just those 3 lines up top, though I must admit I'm not sure what *-anchor does in pf.
14:27:10 <DarkUranium> rtprio, disabled all of appjail stuff, pf, etc --- rebooted --- still nothing :(
14:27:27 <DarkUranium> ifconfig now only has vm-public, tap0, jext, em0, and lo0.
14:27:37 <rtprio> and the wifi is still renamed to jext?
14:27:46 <DarkUranium> Yeah, that's the one thing I didn't undo (yet)
14:28:06 <DarkUranium> Guess I'll try that.
14:28:11 <rtprio> i don't know, i run mine interface on a vlan
14:39:22 <DarkUranium> Still nothing, even without the rename. It might be an Alpine-specific problem, but frankly, I'm calling it a day -_-
14:43:37 <rtprio> i doubt it very much that this has anything to do with your vm
14:56:21 <DarkUranium> So do I, but at this point, I'm about ready to start throwing things at a wall and seeing what sticks.
14:58:35 <rtprio> we;;, i have had weirdness with bridging and wifi before
15:00:43 <DarkUranium> Yeah, fair. I generally use wired for everything, but I happen to have run out of ports, and it's only a test thing anyway.
15:19:55 <DarkUranium> rtprio, I just tried it with em0. Notably, `vm switch add public jext` (again renamed to keep config the same) took a few seconds, unlike before.
15:21:05 <DarkUranium> Also, DHCP worked immediately. Huh.
15:21:12 <DarkUranium> So yeah, it was wlan that was the problem, it seems?
15:46:51 <DarkUranium> rtprio: So yeah, everything works now. I've no idea what's different with wlan vs eth, but ...
16:04:48 <rtprio> i don't know, but as i suspected
16:05:29 <rtprio> there are hacky was you could work around it, but they are hacky
17:32:57 <uskerine> Hi, I have read somewhere that if you append a small amount of bytes to a file the operation is atomic. Could someone confirm/deny or provide more details on the expected FreeBSD behaviour? thanks
17:41:29 <rtprio> uh, i don't think there's any empirical evidence of this
18:00:58 <markmcb> is there any list of "whats new" in 14.2? it'd be nice if something like this was linked to on the release timeline page. without it, beta testing is reduced to "just see if anything breaks"
18:20:08 <mzar> rtprio: it will be detailed listed here https://www.freebsd.org/releases/14.2R/relnotes/
18:25:18 <rtprio> markmcb: looks like "not much"
18:26:28 <markmcb> ok, thanks. just making sure there wasn't some hidden draft list everyone knew about but me.
19:23:24 <CrtxReavr> This is some wierd shit to see in my auth logs: https://termbin.com/sgqw
19:25:54 <rtprio> CrtxReavr: ssh scanners
19:26:03 <rtprio> quite common, not very weird, really
20:02:42 <drijen> CrtxReavr: i think you should review your sshd setup/firewall
20:04:16 <CrtxReavr> Did you get that suggestion off a cereal box?
20:04:41 <rtprio> perhaps he means 'fail2ban' or similar
20:05:00 <rtprio> i ignore them; with key only they're not going to get very far
20:12:53 <CrtxReavr> Clearly they were sending \\admin as the username (or actually \\\\admin since the \s need escaped).
20:13:18 <CrtxReavr> If you're authing against windows, you may need to send domain\\user
20:13:38 <CrtxReavr> Seeing \\admin in the logs was just curious.
20:14:52 <CrtxReavr> I did wonder if it might match a CVE or something.
20:14:57 <rtprio> i've seen all sorts of weird shit
20:28:02 <drijen> CrtxReavr: no need to be an asshole.
20:30:25 <CrtxReavr> There's no need to spout inane nonsense, either.
21:50:30 <rwp> Anyone operating a public Internet server is going to be subjected to the Internet background radiation of endless probes and attacks.  That's just the normal thing these days.
21:51:06 <rwp> Trust in the math.  Just because someone is probing attempting an attack does not mean they are going to be successful.  It's just a log filler.
21:51:40 <rwp> To avoid them filling up the logs tools like fail2ban (and FreeBSD's blacklistd and sshd patches) are both useful to limit the miscreants.
22:44:36 <uskerine> https://stackoverflow.com/questions/1154446/is-file-append-atomic-in-unix
22:44:51 <uskerine> would FreeBSD be POSIX-alike in this ?