81–90 of 244 posts
This makes me kind of sad. Even if it’s just for a private/local usage. IPv6 has the features of ARP built in via “neighborhood discovery protocol” (NDP) with the addition of various security to prevent spoofing.
> Disable IPv6: this approach relies on ARP, which IPv6 doesn't use I wish more people would care about IPv6.
> Disable IPv6: this approach relies on ARP, which IPv6 doesn't use This makes me kind of sad. Even if it’s just for a private/local usage. IPv6 has the features of ARP built in via “neighborhood discovery protocol” (NDP) with the addition of various security to prevent spoofing.
Earlier quoted context omitted.
I have no idea how it looks on the dev/setup side, but suspend and resume is definitely a solved problem, seeing that I've never had any problems with it on my Steam Deck
It's very likely designed for that use case so not very relevant. Most PC are delivered with Windows, and even though Linux works on them, it's unlikely the PC were designed with suspend stability as criteria.
> Disable IPv6: this approach relies on ARP, which IPv6 doesn't use This makes me kind of sad. Even if it’s just for a private/local usage. IPv6 has the features of ARP built in via “neighborhood discovery protocol” (NDP) with the addition of various security to prevent spoofing.
I thought you could run IPv4 and IPv6 at the same time, or am I missing something?
The concept of "ARP Stand-in" brought to mind Proxy ARP: * https://en.wikipedia.org/wiki/Proxy_ARP
With this ARP stand-in, it provides the server's MAC to the client so subsequent traffic to the server doesn't need to pass through the Pi.
This looks like one of those home server infrastructure setup rabbit holes I would've bailed out of within the first 10 minutes of Googling to research the problem. I commend the author for their perseverance and the writeup - rabbit hole writeups are their own form of entertainment. That alone was worth it. I could never run anything that looks like such a conceptual pain the butt. A pain to maintain and troubleshoo…
Meh, I struggled to get my pi to work as a time machine server. It would work for a few weeks and then just stop working and I would have to start the backup from scratch previous backups becoming unusable. In the end I just plugged an external hard disk into the mac. I have had similar issues in the past even with such simple things as SSH to a Mac. It would be easy to blame the pi or Linux, but as far as I can tell…
This site has excellent articles on Time Machine - scroll down to Time Machine Problems: https://eclecticlight.co/mac-troubleshooting-summary/
For the second always-on machine, a router running OpenWRT would be ideal since it would always be up anyways.
Related discussion 14 days ago: https://news.ycombinator.com/item?id=35447094
Earlier quoted context omitted.
Especially when the reality is… you can almost go IPv6 only nowadays if you wanted to. I went down the rabbit hole recently, switching my network to IPv6 primary with IPv4 as the fallback. The ultimate test was disabling IPv4 for a weekend to see what, if anything, broke. I had set up DNS64, NAT64 and 464XLAT. The only weirdness is how Windows clients handle IPv6 literals in UNC paths, which is super ugly, and how so…
464XLAT should work fine with ipv4 literals, no? At least on macOS, this will get routed to a local 192.0.0.2 interface, which does the CLAT, translates it to an ipv6 64:ff9b:: address, and relays it to your nat64 server. The ipv4-only software doesn't know any different, and the only traffic going on your LAN is ipv6. I'm not sure if windows works the same way though... (Edit: Looks like windows can do this, but it…
I appreciate my son being patient on that one, but he appreciated how seriously I dug into everything. Again, we have IPv4 enabled again as fallback, but the family agreed for an IPv6-only weekend as a test, and that was the only thing (outside of one website) that failed.
Everything else worked perfectly, including tons of legacy devices and software, some of which had no concept of IPv6.
For 464XLAT on clients, phones are actually the leaders here. It’s worked perfectly on at least iOS (and I assume Android) for a LONG time because of its built-in automatic tunneling. Mac OS had some recent improvements in Ventura to make things easier. Windows absolutely has some quirks, the biggest being IPv6 literals in UNC paths ending up using a domain Microsoft doesn’t actually own - a potential huge future attack vector.
Saying Windows has had it since Windows 98 and then, acknowledging that the issue is wake-on-demand is a bit confusing to say the least. Obviously Linux can sleep easily since decades ago. The issue is wake on demand (and I don't know if Windows has that even) Edit: I don't why everyone's having issues. I run Fedora on a cheap Gigabyte G5KD and never had any problems. Never did with either of my thinkpads or my Xiaom…
> Obviously Linux can sleep easily since decades ago. Yeah right. Suspend and resume is still buggy as hell. Power management in general in Linux is still awful after all these years.