00:05:04 lw: wait you have your own pastebin setup? 00:08:33 O 00:08:38 Err, mistype. 00:09:41 I've been thinking of setting up https://github.com/solusipse/fiche on the spare domain I have. 00:09:42 Title: GitHub - solusipse/fiche: Command line pastebin for sharing terminal output. 00:10:34 It is, of course, in ports. 00:12:14 what does it mean by requiring a separate webserver to share the output? 00:12:24 you're supposed to configure that webserver a certain way? 00:14:30 fiche receives data from netcat and creates a html file that can be served by a http daemon of your chioce 00:14:34 choice* 00:16:57 oh. cool! 01:37:02 Periodically on my machine on my private LAN I am seeing this logged and I don't understand what would cause it. 01:37:08 Mar 8 17:45:24 madness kernel: Limiting closed port RST response from 270 to 198 packets/sec 01:37:15 Is there any wisdom from the group for me about it? 01:52:27 is there some local process repeatedly trying to connect to a port that doesn't have any listener? 01:53:45 i usually see that with ICMP Unreachable because of UDP though, where it'd be common to see a lot of udp messages all generating the ICMP response hence the high rate. not sure why it would be so high for TCP in your case 01:53:52 Hmm... Not that I know of. And that is why I mentioned it's my desktop on my private LAN. There isn't a public Internet attacking it. 01:54:07 dunno 01:54:40 I dunno either. It's a curiosity. 01:55:23 I am thinking I might fire up pf because I think with the right configuration I can get it to log what is happening and then I would have a log that points to something. At that point I would probably find something I know about but have forgotten about. 01:55:39 yeah 01:55:44 maybe https://brendangregg.com/DTrace/DTrace_Network_Providers.html#Examplessec 01:55:45 Title: DTrace TCP Provider 01:56:16 not 100% sure if that specific example pertains to RST in this situation though (seems to) 01:56:37 (the one under "Detect TCP connect() scan") 01:57:00 Very interesting. Filing that one off for detailed reading. Thanks! 01:57:13 same 14:15:04 Bah. X stopped working (blank screen) following a "pkg upgrade" about 8-9 hours ago. I suspect there's a connection between Xnot working and the upgrade, but I'm at a loss how to figure out which of the 90ish (IIRC) X-related packages, alone or in combo, is responsible for it, assuming that's not one of the other 850ish packages instead. Nothing jumps out to me in Xorg.0.log, and "pkg upgrade -f" 14:15:10 didn't help. (I didn't "pkg clean", so restoring the old package(s) should be possible, if tedious,) GPU is i915, and kldstat shows i915kms is loaded. Clues/ideas/requests for more info all accepted. 14:41:31 OK, on a hunch, I just tried "startx &" and it mostly worked. By which I mean, it started Xfce, but didn't autostart my applications. So the problem may be related to slim or Xfce, not X itself. Or it may be a new race condition. 17:52:36 Hi, i wanted to give containerd / ctr a try, but i was not able to run a command. I tried to run "uname -a" on alpine:latest, but got an "Operation not permitted" on some mount command. So i tried to do the same mount in the shell -- still receiving "Operation not permitted": 17:52:37 % mount -v -o ro -t zfs zroot/DATA/home/containerd/3 /var/run/user/1001/test 17:52:37 mount: zroot/DATA/home/containerd/3: Operation not permitted 17:52:38 zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls, vnodes: count 7995 ). 17:52:38 Any ideas? Would be great, thanks in advance... 17:56:19 What user are you running that as? "%" prompt would suggest non-root. 17:56:29 yes, non-root 17:57:29 I think that"s your problem. 17:57:56 did you do that zfs allow stuff needed? 17:59:14 what zfs allow stuff? I did sysctl vfs.usermount=1... zfs dataset created with zfs create -o mountpoint= ... and then property canmount=on 18:01:42 pretty sure you need zfs allow -u mount too 18:05:11 i tried both datasets default and home/containerd with zfs allow but no effect 18:09:16 hm, no idea why mount doesn't work, but zfs mount should work now 18:09:48 i'm on 14.0-RELEASE 18:57:41 Okay, we have a new winner for worst PTR record ever: 2001:07f8::223c:0000:0004 18:58:08 where did you find that? 18:58:34 Friend stumbled upon it in his travels. 19:03:26 what's so bad about it ? 19:03:52 * CrtxReavr stabs rtprio (in the face). 19:05:15 i feel like i'm missing something 19:08:59 host 2001:07f8::223c:0000:0004 | wc -c 19:09:07 That doesn't strike you as excessive in any way? 19:12:28 hm, seems similar to other IPv6 addresses I tested just now 19:16:43 With the MAC in there as a separate field? 19:17:56 CrtxReavr: no, ptr records have to have each byte 19:18:04 when they're :: there are implicit zeros 19:18:07 What? 19:18:25 I get .ip6.arpa domain name pointer 19:18:38 i don't get it 19:18:53 nimaje, yes. . . that's not wholly un-common. .. but did you look up the one I pasted? 19:19:15 the ip6 of 1::1 is really 1:0000:0000:0000:0000:0000:0000:1 19:19:21 $ host -t ptr 1::1 19:19:21 Host 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.ip6.arpa not found: 3(NXDOMAIN) 19:19:25 It all depends upon how they have delegated the subdomains for the ptr records. 19:19:40 rtprio, run: host 2001:07f8::223c:0000:0004 19:19:52 yes, 4.0.0.0.0.0.0.0.c.3.2.2.0.0.0.0.0.0.0.0.0.0.0.0.8.f.7.0.1.0.0.2.ip6.arpa domain name pointer de-cix.fra.de.as8764.telia.lt. to be exact 19:20:04 4.0.0.0.0.0.0.0.c.3.2.2.0.0.0.0.0.0.0.0.0.0.0.0.8.f.7.0.1.0.0.2.ip6.arpa domain name pointer de-cix.fra.de.as8764.telia.lt. 19:20:05 yeah, what nimaje said. nothing unusual about that 19:20:13 regular thing0 19:20:14 ? 19:20:16 I don't see anything unusual either. 19:20:29 every ptr for ipv6 will look like that 19:20:53 seems good naming too 19:21:23 Holy shit. . 19:21:35 It literally resolved to this just a few mintues ago: mac-4c-f9-5d-3a-26-92.ipv6-2001-07f8-0000-0000-0000-223c-0000-0004.pas-10359.10giga.de-cix.fra.de.as8764.telia.lt 19:22:39 looks like they like longer hosts 19:23:50 could be good in some places 21:24:54 * exoflux has a USB-attached CDROM-drive recognized by freebsd 14.0-RELEASE-p5 as /dev/cd0 21:25:46 * exoflux likes to watch a movie. 21:26:10 it's probably a DVD drive, if you watch movies 21:26:28 yes, it's a DVD 21:27:12 thanx for the askin, la_mettrie. Do I have a special device for DVD? 21:27:58 sometimes it is easy to watch a movie. Sometimes like today it seems impossible... 21:28:26 may, it's because it has some kind of protection mechanism 21:28:50 or I am totally mistaken with the handling of the drive. 21:28:58 * exoflux bamboozled 21:31:53 it'd probably be easier just to get the movie DRM-free from bittorrent rather then dealing with defective by design media 21:32:16 you won't have to sit through a ton of ads before you can watch your movie either 21:32:24 and you can probably get it in higher quality 21:35:10 dvd can have drm too, but that is broken, see decss 21:40:05 Hm, sfox, smart move you recommend... this DRM_free torrent... 21:51:29 Although I have seen the opening of the drive by a command-line some time..., today, with I tend to get "eject: ejecting media from /dev/cd0" and then "eject: Invalid argument" 21:55:36 exoflux: i'm not sure what you mean 22:02:53 * exoflux read sfox's reply now. 22:04:41 sfox, thanx for the askin! Although the drive-info I get about the hard- and software I don't get any control... 22:05:23 i meant about the previous thing you said 22:06:49 I put in an audio-CD and don't get anything, But I also experienced that I did on other days.. 22:07:04 same with the DVD 22:07:59 hi, anyone in eu seeing ssl timeout issues with git.freebsd.org ? 22:09:49 f451: works fine here 22:15:27 how odd 22:15:46 ive tried gitlab over ipv6 - works fine here 22:15:59 just git.freebsd.org over ipv6 22:16:28 sfox! I successfully installed ctorrent and found myself a torrent to my DVD-movie! 22:18:05 dstolfa: amd64 or arm64? 22:18:57 oh good 22:20:22 it's fine for amd64, just not for arm64 - 3 different OSes (freebsd, debian & openbsd), from 3 different ipv6 ip addresses. ipv4 is fine 22:22:18 dstolfa: amd64 is fine. all the ipv6 ips are from the same /64 22:40:14 f451: works fine on arm64 and morello for me, so i don't think it has to do with that 22:41:05 what are you trying to do? 22:43:00 trying to solve an ipv6 issue my rpi4 was having with git.freebsd.org 22:43:13 i noticed git wasn't updating 22:43:42 thought maybe the install was hosed - do did a non-hosed install of raspios 22:43:51 found the same issue 22:44:12 so tried openbsd, installed that, same issue 22:45:18 dstolfa: just with git.freebsd.org and just on arm64 and just on ipv6. gitlab works fine, for ipv4/6 all arches 22:45:42 what happens if you curl it? 22:46:53 i'll try that. i ran debug on the git clone, ultimate output is fatal: unable to access 'https://git.freebsd.org/src.git/': SSL connection timeout several lines after the connect handshake 22:46:54 Title: src - FreeBSD source tree 22:49:07 exoflux: given how old the DVD format is, I find funny how blu-ray is not talked about much but that's probably due to streaming being way more popular and most folks stopped purchasing physical media all together. 22:50:04 dstolfa: debug from git - 21:26:50.512185 http.c:820 == Info: Trying [2604:1380:4091:a001::24ca:1]:443... 22:50:18 let me try to git that address directly 22:50:25 there are 2, maybe i'm hitting the other one 22:50:38 Info: Connected to git.freebsd.org (2604:1380:4091:a001::24ca:1) port 443 22:54:41 ALPN: curl offers h2,http/1.1 22:55:03 TLSv1.3 (OUT), TLS handshake, Client hello (1): 22:55:07 f451: i'm able to curl the ipv6 address just fine from everything, but i can't figure out how to get git-clone happy with the ipv6 address lol 22:55:45 use it like [ipv6address] 22:55:54 i did, it's very unhappy with that for some reason 22:56:01 https://[ipv6address] 22:56:07 ah whats yr shell 22:56:19 i use ksh or tcsh 22:56:37 try from sh 22:58:08 on openbsd sh is aliased to ksh argh 22:59:04 it might be that https:{blah} wont owrk if the cert doesnt have that ip in it i guess - hmm git:// should work? 22:59:06 f451: seems like it's an invalid certificate for that address. try it in your browser 22:59:09 https://[2604:1380:4091:a001::24ca:1]/src.git 22:59:28 Unable to communicate securely with peer: requested domain name does not match the server's certificate. 23:00:19 just quote your shell meta characters instead of relying on the shell to quietly discard failures and assume it is a string literal then 23:01:14 curl -v -6 https://git.freebsd.org/src.git - stops at CAfile: /etc/ssl/cert.pem CA Path: none 23:01:15 Title: src - FreeBSD source tree 23:01:17 with curl you could use --resolve, no idea if git has something similar 23:02:24 with git i used export GIT_TRACE_PACKET=1 export GIT_TRACE=1 export GIT_CURL_VERBOSE=1 23:03:22 but those don't help you to specify which ip you want to use for a domain name 23:04:12 you could set it in /etc/hosts temporarily 23:04:59 set it to one ipv6 ip and it should use that 23:09:58 i can get to https://git.freebsd.org/src in lynx it (nginx) rewrites to cgit 23:09:59 Title: src - FreeBSD source tree 23:13:07 f451: forwarded the information to the people who can fix it :). probably tomorrow, though. it's late and a saturday 23:13:32 :D 23:13:44 you did? 23:13:58 dstolfa: xlnt! 23:14:45 i'll make a PR if you think they'll need it, have lots of debug output 23:15:21 f451: probably worth doing. more information is always useful 23:15:49 okeydoke, many thanks for yr assistance, have a good night ;) 23:16:30 f451: thanks for taking the time to report it and debug 23:20:23 guys i have problem with pkg, please look https://pastebin.com/sFfSYRkr 23:20:24 Title: [2319][root@kilitary:~]$ pkg update && pkg upgradeUpdating FreeBSD repository - Pastebin.com 23:20:29 what i should do 23:25:22 xFCFFDFFFFEFFFAF: you should update your kernel 23:26:04 dstolfa: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277606 23:26:06 Title: 277606 – https://git.freebsd.org SSL connection timeout out over ipv6 23:26:09 It's time for a "freebsd-update upgrade -r 13.2" 23:26:28 ok, will try now 23:26:37 f451: thanks! 23:26:39 *13.2-RELEASE 23:28:18 * xFCFFDFFFFEFFFAF updating ... 23:52:39 * xFCFFDFFFFEFFFAF updating ... complete