farcaller

joined 1 year ago
[–] farcaller@fstab.sh 1 points 9 months ago

I’ll make a note here that a firewall is useful for internal traffic, too. Those IoT devices can get pretty annoying, so you'd want to e.g. drop your cheap webcams into a VLAN and disallow them from talking to enjoying but their cloud, and especially the other VLANs, or isolate Alexa capable device so it won’t try to figure what else you got there in your house over mDNS (it will).

A managed switch would do nicely. Having isolated ports on the switch (and the wifi AP) is also great if you want to make sure the specific device will only talk to the gateway and not its peers.

[–] farcaller@fstab.sh 1 points 10 months ago* (last edited 10 months ago) (1 children)

Here's how it works: unifi devices need to communicate with the controller over tcp/8080 to maintain their provisioned state. By default, the controller adopts the device with http://controller-ip:8080/inform, which means that if you ever change the controller IP, you’ll must adopt your devices again.

There are several other ways to adopt the device, most notably using the DHCP option 43 and using DNS. Of those, setting up DNS is generally easier. You'd provision the DNS to point at your controller and then update the inform address on all your devices (including the USG).

Now, there's still a problem of keeping your controller IP and DNS address in sync. Unifi, generally, doesn’t do DNS names for its DHCP leases, and devices can’t use mDNS, so you’ll have to figure a solution for that. Or, you can just cut it short and make sure the controller has a static IP―not a static DHCP lease, but literally, a static address. It allows your controller to function autonomously from USG, as long as your devices don’t reach to it across VLANs.

[–] farcaller@fstab.sh 2 points 10 months ago (3 children)

Unifi is specific about expecting the controller address to not change. You have several options: There's the “override controller address” setting, which you can use to point the devices at a dns name, instead of an ip address. The dns can then track your controller. It doesn’t exactly solve your issue, though, as USG doesn’t assign dns names to dynamic allocations.

Another option is to give the controller a static IP allocation. This way, in case you reboot everything, USG will come up with the latest good config, then will (eventually) allocate the IP for controller, and adopt itself.

Finally, the most bulletproof option is to just have a static IP address on the controller. It's a special case, so it's reasonable to do so. Just like you can only send NetFlow to a specific address and have to keep your collector in one place, basically.

I'd advise against moving dhcp and dns off unifi unless you have a better reason to do so, because then you lose a good chunk of what unifi provides in terms of the network management. USG is surprisingly robust in that regard (unlike UDMs), and can even run a nextdns forwarding resolver locally.

[–] farcaller@fstab.sh 9 points 10 months ago (1 children)

It's more of a chat-to promotion than a useful list. “Use firewalls?” No shit!

[–] farcaller@fstab.sh 7 points 10 months ago (4 children)

from the left screen edge towards right.

[–] farcaller@fstab.sh 45 points 10 months ago (4 children)

However, XAMPP didn’t just die because it opened itself up to Microsoft and got extinguished

So, we went from the somewhat imaginary “google killed xmpp” to fully fictional “Microsoft killed xampp” now? it's almost like the fedipact people literally have no clue what they are talking about.

[–] farcaller@fstab.sh 3 points 11 months ago

I took a look at the current traffic and you’re absolutely correct, lemmy (as of 0.19) has a proper schema with everything covered!

[–] farcaller@fstab.sh 3 points 11 months ago (2 children)

But lemmy doesn’t use “plain json”, it annotates some fields with the schema, just not all of them, which makes it a mess. You either do json-ld proper, or you don’t do it at all.

[–] farcaller@fstab.sh 12 points 11 months ago* (last edited 11 months ago) (4 children)

no Federation with instances that use altered versions or proprietary versions of AP.

It's especially funny given (the last time I checked) neither kbin nor lemmy actually followed the spec properly. They ignore the jsonld requirements and resort to field names, that, by the spec, should be dropped.

Edit: lemmy is actually good now!

[–] farcaller@fstab.sh -1 points 11 months ago (1 children)

I can easily imagine the future where “good” instances will then stop federating with the ones that don’t have threads blocked, all thanks to these lists.

[–] farcaller@fstab.sh 5 points 11 months ago (1 children)

isn’t threads already several times larger than the whole of the “fediverse”?

[–] farcaller@fstab.sh 8 points 11 months ago

In iOS 13 or later and iPadOS 13.1 or later, devices may use an Elliptic Curve Integrated Encryption Scheme (ECIES) encryption instead of RSA encryption

(from apple docs).

If you’re curious about it all, I'd suggest studying some notes from the protocol researchers instead of taking to the pitchforks immediately. Here's one good post on the topic.

view more: ‹ prev next ›