I think I’ve found the problem:

It seems my issue is pihole being unable to block/modify dns requests for HTTPS records, which don’t match the LAN IPs pihole handed out in A/AAAA records.

I’ve disabled cloudflare proxying so they don’t have HTTPS records to serve, but I’ll have to replace pihole with a better lan DNS solution if I want to turn that back on.

Thanks. That seems to be a similar, but slightly different error. I think the below may apply though.

I believe I’ve tracked down more of my issue, but fixing it is going to be a hassle:

When cloudflare proxying is enabled, there are 3 DNS records involved; A record with cloudflares ipv4, AAAA record with cloudflares IPV6, and the key to this puzzle: an HTTPS record with cloudflares ech/https config.

With pihole I can set DNS records for A/AAAA, but I have no way of blocking/setting the HTTPS record so it gets through from cloudflare.

The LAN A/AAAA records don’t match the HTTPS record from cloudflare, so browsers freak out.

Once I disabled cloudflares proxying, I no longer get HTTPS records returned and all works as intended.

I’ll either have to keep cloudflare proxying disabled, or switch pihole out for a more comprehensive DNS solution so I can set/block HTTPS records :(

Thank you @bobslaede@feddit.dk for pointing me in the right direction.

That unfortunately did not work. I am only getting the ipv4 address now, but I still get the same ECH error in chrome 1/5 tries.

Firefox now changed errors from ‘invalid certificate’ to ‘connection is insecure but this site has HSTS’ (true). Still wont show the cert or provide any further info. (forgot to grab a screenshot before the below ‘solution’)

I’m really annoyed at this point and have just disabled cloudflare proxying for this service. That seems to have sorted it for all browsers. I may look further later, I may just say fuck it and leave it like this. Gotta walk away for a bit.

I’ll look into that next if what I’ve done doesn’t work. (see other comments)

Added an AAAA record to pihole:

ombi.mydomain.example 0000:0000::0000:0000

Now nslookup returns the correct ipv4 address, and ‘::’ as the ipv6.

We’ll see if that works.

Crap, looks like that’s exactly what it is.

Now how to fix that…

I do have external acces to Ombi via cloudflare; but the device I’m seeing this problem on is permanently connected to a VPN hosted from the same server machine as ombi/nginx with ‘block all connections without VPN’ enabled. And this testing has been done from within the same LAN.

It should never see/reach cloudflare for this service.

/edit; I’ve also disabled ‘use secure DNS’ in chrome. I host a local DNS within that lan/vpn network.

You’ve done enough, keeping it behind your routers firewall.

You could block LAN access and require a VPN connection to that specific machine if you really wanted more, but I’m not that concerned about it.

Yup. Point is; if you’re not depending on just its login page to keep it secure, there’s not a whole lot needing ‘security patches’, so I wouldn’t be all that concerned about slow updates. As long as it remains bug free, I’m happy.

I’m always a bit put off when she shows off her dick.

But, look at that perspective shot; that thing is HUGE! You definitely want to sleep with me now right? Right??

And security patches

Something with the power of dockge should be behind a seprate form of authentication imo.

I only access it via VPN, it’s not exposed to WAN.

Yes, obviously that’s always been an option.

I dont see a good solution for the topic we were actually talking about: creating high-power public use charging ports.

Considering how old Facebook is, you’d think they would have their shit together when it comes to password security…

It’s not so much the connector; but the power delivery standard.

Type A maxes out at 5v 3a = 15w and is often limited closer to 5v 1a = 5w for public-use charging ports.

Type C and its power delivery standards can get as high as 50v 5a = 250w (though usually closer to 20v 5a = 100w)

Then again… The negotiation for what voltage/amperage to supply happens over the data lines which you don’t want connected on a public charging port…

I dont really see a good solution here.

Takes forever to bring the charge up; but perfect for maintaining battery while you watch/scroll on trips.

I tend to just use FolderSync myself. To avoid battery issues, I have a schedule for most folders; but my DCIM/Pictures folders sync immediately upon changes. I then have a widget on my homepage that triggers a ‘sync all’. Anytime I need files synced immediately, it’s easy enough to click that button.

1. it doesn’t necessarily take full resolution images

2. just because it can capture images a few hundred milliseconds apart doesn’t mean it’s continuously capturing images. It could be several in short bursts with a delay between groups of images.

Depends on where I’m scrolling and how long.

In a specific community? Usually sorted by ‘new’.

‘Subscribed’/‘All’ feeds? Generally starting with ‘Hot’ then moving to ‘new’ if I start to run into a bunch of content I’ve already seen.

Yeah, busses only pick people up at stops; they’re not allowed to get off until the end of the route…