00:07:42 <fonks> It was already strange on m68k, but manageable (A-traps come to mind); powerpc was a little weird (MCEs on address misalignment, anyone?); I've not read the m88k docs enough to know how bad it was for that one though
00:08:07 <fonks> seems to be Motorola's signature to have strange, unconventional exception mechanisms
01:00:30 <RhodiumToad> dammit, I hate when the documentation lies
01:01:05 <timothias> Careful reading medical journals, you may die of a misprint. (I think that's Mark Twain)
01:01:45 <RhodiumToad> and now I need to write a test program to see whether I'm right or whether the documentation is
01:03:26 <timothias> What is the test?
01:03:32 <timothias> and how do you think they are wrong?
01:04:31 <RhodiumToad> the docs for the login class functions, login_get* etc., say that returned pointers are not to be freed, that memory will be reused or freed by login_close
01:04:46 <RhodiumToad> but the code doesn't look like it does that
01:06:33 <timothias> credentials?
01:06:49 <timothias> cause thatd be kind of bad
01:07:45 <RhodiumToad> actually memory leaks from the login class stuff would almost never matter. the code that uses them is almost always about to do an exec()
01:08:23 <RhodiumToad> and there's nothing sensitive in the data, it's just from /etc/login.conf which is publicly readable
01:10:11 <timothias> what if their avatar is questionable?
01:10:12 <timothias> :D
01:10:42 <RhodiumToad> looks like I'm right.
01:10:54 <timothias> get a bug bounty
01:11:15 <timothias> buy a steamdeck
01:11:22 <timothias> terraria for the win!
01:14:15 <RhodiumToad> oh look, it's an already-reported bug
01:14:26 <RhodiumToad> nearly 10 years old
01:14:55 <xtile> RhodiumToad: link it
01:24:56 <mason> RhodiumToad: That bug can't even drink or vote yet. Hardly counts.
01:25:27 <RhodiumToad> I think it should probably not be fixed. I think the right thing would be to fix the manpage, and possibly the callers.
01:26:13 <ek> Just out of curiosity, is anyone else having issues doing DNS lookups/digs/drills for freebsd.org or forums.freebsd.org? I keep getting SERVFAIL's and BAD REFERRAL errors.
01:26:42 <ek> Doesn't seem like it's directly related to only *.freebsd.org, rhough.
01:27:03 <mason> Not seeing anything here from a quick check.
01:27:48 <RhodiumToad> looks ok to me too.
01:29:01 <ek> Hrm. Something is definitely screwy over here. Thanks!
01:29:48 <ek> Of course, it's only screwy if I do caching-only and don't use any forwarders.
01:30:02 <ek> I thought it was a DNSSEC issue but I disabled that, too.
01:30:28 <ek> Failing somewhere on ROOT server lookup.
01:30:32 <RhodiumToad> make sure that either you have working ipv6 or that your nameserver knows not to use ipv6
01:30:58 * RhodiumToad files bug
01:31:04 <ek> I do have working IPv6 but I also set it to IPv4 only to test that as well.
01:31:28 <RhodiumToad> what kind of output are you getting from drill?
01:31:44 <ek> It depends on what I try, I suppose.
01:32:05 <RhodiumToad> that's an invitation for you to show an error
01:32:17 <ek> Okay.
01:34:11 <ek> I get this when I just try a simple "drill forums.freebsd.org": http://paste.purplehat.org/view/765e80be
01:34:15 <VimDiesel> Title: DNS derps - PHO Paste
01:36:27 <RhodiumToad> 2603:300b:3ba5:6101::108 is your local resolver?
01:38:46 <ek> Yeah. It's a local v6 IP on the server. Just connecting to itself.
01:39:19 <ek> Slightly tweaked to mask the real IP. Not sure why. It's easily looked up. *shrugs*
01:40:13 <RhodiumToad> can you tcpdump the actual queries being sent by your nameserver and the responses?
01:49:26 <ek> RhodiumToad: I believe so.
01:53:49 <ek> http://paste.purplehat.org/view/db3747c4
01:53:53 <VimDiesel> Title: DNS derps two - PHO Paste
01:54:17 <ek> I'd imagine that's not a deep enough dive into the packets to get much info. I'd likely need to grab a pcap or something.
01:56:09 <ek> http://paste.purplehat.org/view/9613dad2
01:56:11 <VimDiesel> Title: DNS derps 3 - PHO Paste
01:56:56 <ek> That's more verbose. I do see some bad UDP checksums in there.
02:04:12 <ek> I should actually be asking/sharing this in #dns or #bind or something. I appreciate the help, though!
02:08:13 <RhodiumToad> oh, I bet I know what this is
02:16:01 <ek> RhodiumToad: Do tell!
02:16:27 <RhodiumToad> hm, no, I can't replicate it
02:20:22 <ek> It's super strange. Especially since I've touched nothing. It was working this morning and this afternoon, everything went kaput.
02:20:58 <ek> On not one, but three BIND9 non-forwarding servers.
02:21:05 <ek> Maybe it's an ISP issue?
02:33:40 <RhodiumToad> could be.
02:35:09 <RhodiumToad> here's something to test:  drill whoami.ultradns.net
02:35:50 <RhodiumToad> if the result you get isn't the address of your nameserver, then someone (e.g. your ISP) is intercepting queries
02:36:23 <ek> Returns nothing.
02:36:27 <ek> No A record.
02:36:36 <RhodiumToad> try for an aaaa record
02:37:57 <ek> Okie dokie.
02:39:07 <ek> Same result. And here's what I see in the log: http://paste.purplehat.org/view/1811d13e
02:39:10 <VimDiesel> Title: whoami aaaa log - PHO Paste
02:39:19 <ek> So, it's trying to do the lookup but just gets bad results.
02:39:44 <RhodiumToad> can you resolve anything at all?
02:40:22 <RhodiumToad> what if you do   drill @156.154.69.196 whoami.ultradns.net   ?
02:42:22 <ek> RhodiumToad: Looks like it resolves? http://paste.purplehat.org/view/d6720d2b
02:42:25 <VimDiesel> Title: whoami rDNS - PHO Paste
02:42:46 <ek> NOERROR
02:43:02 <RhodiumToad> shouldn't give 255.255.255.255 tho
02:44:12 <ek> Interesting.
02:44:14 <RhodiumToad> try  drill @2001:502:f3ff::e8 whoami.ultradns.net aaaa
02:45:35 <ek> RhodiumToad: Ah, "drill a @156.154.69.196 whoami.ultradns.net" returns "104.225.12.106".
02:45:48 <RhodiumToad> is that your IP?
02:46:04 <ek> RhodiumToad: The AAAA record attempt returns nothing.
02:46:09 <ek> And, no, that is not my IP.
02:46:39 <RhodiumToad> is it an IP belonging to your ISP?
02:47:25 <ek> Not that I can see trying a rDNS lookup.
02:47:40 <RhodiumToad> whois says  NetActuate, Inc
02:47:53 <ek> dns05-ndfw2-c2szps.001.prd.c2szps.spscld.net is what it resolves to.
02:48:15 <ek> Never heard of NetActuate, Inc. *shrugs*
02:48:46 <RhodiumToad> are you using any kind of vpn or tunnel service?
02:49:11 <ek> Nope. Directly routing through ISP.
02:49:53 <ek> Haha. I'm so insanely stumped.
02:51:02 <ek> It is actually starting to cause issues with one of my mail servers, though. So, I'm getting a bit peeved.
02:51:46 <ek> And, to reiterate, this is only happening when I'm not using forwarders (which also breaks RBL's so it's not an option).
02:52:00 <ek> Why would it only fail for lookups from DNS root servers?
02:52:16 <ek> I'll be missing some hair before this is resolved.
02:54:18 <RhodiumToad> what ISP are you using?
02:55:41 <ek> Crappy-ass Comcast Business.
02:55:50 <RhodiumToad> bingo.
02:56:24 <ek> Thing is, they did a "service upgrade" today (which was only a router battery backup) but I noticed the issues pretty quickly afterwards.
02:56:28 <RhodiumToad> those spscld.net addresses are Comcase Edge Security
02:56:35 <RhodiumToad> *Comcast
02:56:44 <ek> Oh, FFS.
02:56:51 <RhodiumToad> they are definitely intercepting your DNS
02:56:56 <ek> Alright. I'll give them a call then. Morons.
02:56:58 <ek> Thanks!
02:57:24 <RhodiumToad> google turned up various past reports of people having weird DNS issues caused by exactly this
02:57:36 <ek> What was the resolution?
02:57:46 <RhodiumToad> turning it off, apparently.
02:57:59 <ek> Nice. At least there's an option.
02:58:03 <ek> Calling them now.
02:58:10 <RhodiumToad> possibly you had it turned off before and the "upgrade" turned it on?
02:58:44 <ek> That's very possible. I'm not sure what they did. I'll make sure they just disable everything. I don't need any of their security warez anyway.
02:59:00 <RhodiumToad> and possibly there's a way to do it via the website?
02:59:31 <ek> Perhaps. I'll check that out, too. Thanks again!
02:59:33 <RhodiumToad> this might be relevant: https://www.reddit.com/r/sysadmin/comments/s3cgx0/comment/iijh7pf/?utm_source=share&utm_medium=web2x&context=3
02:59:34 <VimDiesel> Title: falling_away_again comments on Barracuda SafeLinks Certificate Error
03:00:42 <RhodiumToad> anyway, it's clear that this is the problem, rather than anything on your end or on freebsd's end
03:01:03 <RhodiumToad> (that ultradns tool can be _really_ useful sometimes)
03:01:35 <ek> Well, I figured it wasn't an issue with my stuff since it was working flawlessly and stopped without changes. I just wanted to make sure it was only me before I started contacting any kind of support.
03:01:56 <ek> Wouldn't taken even longer. Figured someone might be able to point me in the right direction. I really appreciate it!
03:02:15 <RhodiumToad> yw
03:02:20 <ek> I'll keep that ultradns tool under the belt for future testing, for sure.
03:04:28 <ek> DNS is so bad, I can barely use their website. That's a nice touch.
03:10:44 <ek> Yep. Disabled that stupid "Security Edge" and everything appears to be working now. Thanks again, RhodiumToad!
13:46:58 <stipa> is https://forums.freebsd.org/ down for you too?
13:46:59 <VimDiesel> Title: The FreeBSD Forums
13:50:12 <vkarlsen> stipa: Seems to work for me
13:54:12 <ek> Same.
13:54:39 <ngortheone> works for me too
13:57:33 <stipa> dead for me
13:57:37 <stipa> everything else works
13:59:05 <stipa> https://www.freebsd.org/ is fine
13:59:06 <VimDiesel> Title: The FreeBSD Project
14:42:31 <ek> stipa: DNS resolution issue, maybe?
14:45:10 <pstef> is anyone here running a prosody server on FreeBSD?
14:50:04 <stipa> ek: yeah, something on that note
14:51:08 <stipa> i'm not sure why some sites work and some don't
14:51:48 <stipa> could be on the ISP side
14:57:32 <stipa> now i get the response with 'nslookup' but still no forum
14:58:29 <stipa> i changed nothing, must be ISP or something else
15:02:06 <stipa> i accessed the forum for a moment and lost it again after a page refresh
15:27:55 <ek> stipa: What ISP? I just dealt with something very similar with Comcast intercepting/blocking a ton of DNS requests with their "Security Edge" proxy/sniffer/filter/whatever... It's awful.
15:34:41 <gustik> any idea why AT refuses to work for a user? atq: you do not have permission to use this program
15:36:06 <gustik> ppl should run their own dns resolver
15:37:32 <gustik> and dont forget about DNSSEC some ppl do not know how to implement it properly and that causes DNS to sometimes resolve and sometimes not
15:38:29 <CmdLnKid> have you read the man page ... /var/at/at.allow
15:39:43 <ek> gustik: I do run my own resolvers. Doesn't stop the ISP from sniffing/filtering plaintext record lookups from root servers, though. It's a bummer DoT/DoH isn't supported by root servers (yet).
15:41:04 <gustik> you do not need that
15:41:17 <gustik> DNSSEC should check for it
15:41:40 <gustik> there are checksums for DNS replies so that when some ISP changes the answer it gets thrown out
15:41:44 <ek> DNSSEC won't help with ISP DNS query interception.
15:42:04 <ek> Exactly. And you get no or bad results which breaks DNS.
15:43:20 <ek> Encrypted queries to root DNS servers would prevent interception and MITM replies.
15:43:29 <ek> Well, one would hope.
15:44:00 <gustik> so they are censoring the internet or what
15:44:13 <gustik> because why otherwise would someone filter the root dns replies
15:44:32 <gustik> if it is only affecting root dns stuff
15:44:48 <CmdLnKid> they arent sensoring it, they are collecting and selling your queries
15:45:09 <gustik> one would need a dns resolver that's resolving properly and then connect to it using VPN or DoH
15:45:45 <gustik> so they try to inhibit you from running your own resolver in order to sell your data?
15:52:43 <ek> gustik: That seems to be the case. They claim it's for "safety" but the replies they were returning were WILD.
15:53:21 <ek> https://www.reddit.com/r/sysadmin/comments/134jtdy/psa_comcast_is_breakinghijacking_dns_with_their/
15:53:23 <VimDiesel> Title: PSA: Comcast is breaking/hijacking DNS with their "Security Edge" product : sysadmin
15:55:43 <gustik> everything is on reddit now
16:03:03 <CmdLnKid> moot
16:42:39 <stipa> ek: A1, mobile 4G internet
16:43:08 <stipa> austrian owned
16:44:44 <stipa> ek: could be something similar, i mean, everything i usually do works
16:45:20 <stipa> in meantime i've sent some email, watching YT.., still can't access forum.freebsd.org
16:45:36 <stipa> forums*
16:50:59 <stipa> i think, hmmm, that my local dns server works with 1.1.1.1
16:51:24 <stipa> could be the cloudflare that is an issue
16:51:47 <stipa> i'll try to change it to google server
16:51:59 <RhodiumToad> stipa: try the same test I suggested to ek:  drill whoami.ultradns.net   and see what the IP is (make sure your local resolver isn't forwarding to 1.1.1.1 or other public service first)
16:52:30 <RhodiumToad> what error do you get with forum.freebsd.org?
16:54:08 <stipa> RhodiumToad: https://ibb.co/V30FSRm
16:54:09 <VimDiesel> Title: freebsd-forum-error hosted at ImgBB — ImgBB
16:56:31 <stipa> RhodiumToad: (make sure your local resolver isn't forwarding to 1.1.1.1 or other public service first), what does that mean? i have to have a DNS server, which one if not google or cluflare one?
17:02:49 <ek> stipa: I think we were assuming you were running your own caching or forwarding DNS server locally.
17:03:12 <stipa> i do run a server locally
17:03:47 <ek> If you're just using any random public DNS server, it could be a problem on their end. You could try 1.1.1.1, 8.8.8.8, or 9.9.9.9 to see if the results change. If they don't, the problem is likely not a DNS issue.
17:04:32 <ek> stipa: Ah. If that's the case, just remove the forwarders. This will query root DNS servers only and not use things like Cloudflare or Google.
17:04:50 <ek> Then run the ultradns test that RhodiumToad suggested.
17:06:05 <stipa> wait, i'll check what ISP router has set
17:06:18 <stipa> i turned its DNS server off the moment i got it
17:06:38 <RhodiumToad> you can also do e.g.  drill @156.154.66.196 whoami.ultradns.net
17:07:29 <RhodiumToad> the result should have  whoami.ultradns.net.    0       IN      A       your.ip.here
17:07:56 <RhodiumToad> if it has an IP that's not yours, that's when you know that someone is intercepting your DNS queries
17:08:24 <stipa> hmm, yea there's an ip
17:09:03 <RhodiumToad> is it your public IP, or something else?
17:09:07 <stipa> it's the same as at https://www.myip.com/
17:09:09 <VimDiesel> Title: Check your IP address | MyIP.com
17:09:16 <RhodiumToad> ok
17:10:33 <stipa> wait
17:10:42 <stipa> it's not
17:11:41 <stipa> there's a difference in third column of the ip adress
17:11:54 <stipa> three other columns are the same as my iš
17:11:56 <stipa> ip
17:12:44 <stipa> so, what? that's the DNS server on the ISP side?
17:13:02 <RhodiumToad> it might be. try a reverse lookup on the IP
17:13:28 <RhodiumToad> if this is a mobile provider it's quite possible that you're behind multiple layers of NAT
17:14:23 <stipa> what should i type for reverse lookup?
17:14:53 <stipa> dig -x [address]
17:14:57 <stipa> which adress?
17:15:13 <RhodiumToad> drill -x IP   using the address you got back from whoami.ultradns.net
17:15:23 <stipa> ok
17:16:21 <stipa> i've got something,
17:16:33 <stipa> what am i looking at?
17:18:00 <stipa> i guess the idea is to map all the DNS servers that intercept my queries to a main one?
17:18:10 <RhodiumToad> no
17:18:18 <RhodiumToad> what did you get?
17:19:03 <stipa> RhodiumToad: https://pastebin.com/mfzRLVCc
17:19:05 <VimDiesel> Title: asus@asus:~$ drill -x 95.168.121.39;; ->>HEADER<<- opcode: QUERY, rcode: NOERR - Pastebin.com
17:22:44 <RhodiumToad> ok, those dns names aren't informative, all we can tell is that they're from your ISP
17:22:54 <stipa> yes
17:23:16 <stipa> why would they intercept queries?
17:23:44 <stipa> subnetting?
17:24:27 <RhodiumToad> security, censorship, cacheing for efficiency, monitoring user behavior, gathering marketing data, who knows
17:24:33 <stipa> i would guess DNS repeaters that send queries through subnets
17:25:24 <stipa> but, hmm
17:25:41 <stipa> why would the forums.freebsd.org be blocked in such things?
17:26:40 <stipa> no matter which global DNS server i use it'll my queries will always be filtered
17:27:06 <RhodiumToad> what does  drill @163.237.210.11 forums.freebsd.org    return?
17:27:34 <stipa> nothing
17:27:37 <stipa> empty
17:27:47 <stipa> https://pastebin.com/jWZiTNhK
17:27:49 <VimDiesel> Title: asus@asus:~$ drill @163.237.210.11;; ->>HEADER<<- opcode: QUERY, rcode: REFUSE - Pastebin.com
17:29:16 <RhodiumToad> you didn't type the command correctly
17:29:22 <RhodiumToad> drill @163.237.210.11 forums.freebsd.org
17:30:30 <stipa> right
17:31:02 <stipa> https://pastebin.com/7CyXgCMi
17:31:04 <VimDiesel> Title: sus@asus:~$ drill @163.237.210.11 forums.freebsd.org;; ->>HEADER<<- opcode: QU - Pastebin.com
17:31:39 <RhodiumToad> that looks correct. so DNS probably isn't the issue here
17:32:30 <RhodiumToad> does   drill -T forums.freebsd.org   work?
17:33:56 <stipa> seems so https://pastebin.com/jsxQJRSJ
17:33:57 <VimDiesel> Title: asus@asus:~$ drill -T forums.freebsd.org. 518400 IN NS m.root - Pastebin.com
17:34:26 <RhodiumToad> ok. so your DNS is fine.
17:34:53 <stipa> it's 8.8.4.4. now but still no forum
17:35:04 <stipa> same as with the 1.1.1.1
17:35:16 <RhodiumToad> you may have been blocked from the forum because of misbehavior from other users of your ISP, or there may be some unrelated problem somewhere
17:35:46 <stipa> who knows
17:54:14 <stipa> yeah, works with opera and it's VPN feature
17:54:36 <stipa> proxy is 77.111.247.69
18:18:59 <ek> stipa: Reach out the forum admins and ask about it. They'll probably be able to help you out.
18:20:49 <stipa> ek i'm not a member of the community really, and i guess the conclusion would be the same as you suggested
18:22:09 <stipa> thanks for the proposal
18:22:43 <stipa> actually, what RhodiumToad suggested
18:23:34 <stipa> i've got freebsd in a VM and that's about it
18:24:19 <stipa> if i want to set something or change i sometimes end up on the forum
19:00:26 <meena0> is there a way to output a horizontal line in the terminal, without putting echo "=============================================================" in your script?
19:02:01 <meena0> printf %"$COLUMNS"s | tr " " "-" # apparently, this works in bash
19:02:24 <meena0> wonder if it works in ((t)c)sh
19:03:53 <meena0> works in fish, but not in tcsh
19:04:14 <meena0> doesn't work in sh, either
19:08:49 <gustik> I have been using fish recently but I uninstalled it, it is too heavyweight
19:11:12 <gustik> I like lightweight shells like ksh, but even there I noticed that new ksh is consuming more RAM than old bash, even though bash can do more...
19:13:23 <gustik> I would do printf with - and skip that tr pipe, also ${COLUMNS}
19:14:02 <meena0> gustik:  bash has probably seen a lot more work, because it's a default she'll in many environments, and as such used for scripting, so it's important to be very performant
19:20:32 <meena0> I could set a default, if COLUMNS isn't set
19:29:03 <otis> hi gustik
19:41:51 <meena0> I'm rebuilding alpha.pkgbase.live! cast your wishes for which architectures you want to see (and use)
20:05:38 <rtprio> meena0: does it have to be full width? printf "%80s" | tr " " "-"
20:09:30 <meena0> rtprio: having a sensible default, would be good in case COLUMN isn't set
20:09:53 <rtprio> or `tput cols`
20:10:03 <rtprio> which should work regardless of shells
20:44:45 <meena0> rtprio: thank you, that's exactly what I've been looking for
20:49:05 <tsoome> meena0 https://paste.ec/paste/Ua2uETzN#6vkt5nIMRpivfHXy2tQK5+D7vWJlBADKhHd+D7cDns3
20:49:07 <VimDiesel> Title: 0bin - encrypted pastebin
20:52:30 <meena0> tsoome: did you change anything to get that?
20:53:41 <tsoome> I did allow BLT only pixel mode. ofc the kernel console is not shown because fb address is 0.
20:54:47 <meena0> what's BLT? and why is the fb address at 0?
20:55:11 <tsoome> fb address is 0 because there is only virtual framebuffer
20:56:11 <tsoome> BLT "block transfer" primitive to draw the screen
20:56:44 <tsoome> that is, function from GOP protocol of UEFI.
20:57:08 <meena0> and can a virtual framebuffer be used?
20:58:41 <tsoome> the text is on screen, therefore yes. but I do not have that kernel driver code integrated, so I have no idea how good it is:)
21:01:59 <meena0> So you mean, once past loader, there won't be any displaying until virtio_gpu is loaded?
21:02:18 <meena0> or do i misunderstood?
21:07:25 <tsoome> yes
21:08:45 <tsoome> thats because efifb is built assuming we have framebuffer where we can write pixels (store 32-bit data)
21:17:44 <meena0> tsoome: and why can't we write to a virtual fb? because it needs more bootstrapping? something a driver would do?
21:18:49 <tsoome> virtual fb does not provide video memory to write to
21:22:51 <tsoome> hm, the vm actually does also provide serial console (port).
21:27:11 <meena0> So if virtual fb can't be written to, what is it good for? and if virtual fb can't be used, but serial console exists, why aren't we using that?
21:30:26 <tsoome> meena0 https://paste.ec/paste/ue0NqPW1#IgfOGNHCFUBmCjTpJEk9BbeXrJTeQ0+iiVL5sUJ-OSL
21:30:28 <VimDiesel> Title: 0bin - encrypted pastebin
21:31:30 <tsoome> virtual console does provide functions to write to console, just as does virtual block device and virtual network device. So you would need driver for it.
21:33:23 <tsoome> hetzner actually has serial port feature, but it seems they do not provide interface to access it. or at least it is not  easy to find.
21:51:12 <meena0> tsoome: try a support ticket. tho i wouldn't expect any answers any more
23:15:03 <hyvoid> if I'm setting up alpine linux in a freebsd jail do I need to exec alpine's rc
23:34:52 <mason> hyvoid: Only if you want it. That's the difference between a system container and an application container.
23:48:28 <manu2> hi
23:56:22 <hyvoid> thanks mason