| 27 May 2021 |
| Fabian Affolter joined the room. | 18:03:18 |
| morrpl joined the room. | 20:35:13 |
| 28 May 2021 |
| ijustwannalurk left the room. | 05:37:21 |
| Patrick Georgi left the room. | 09:49:14 |
| 29 May 2021 |
| justinrestivo changed their display name from justinrestivo to oh caml >>=. | 12:21:01 |
| justinrestivo changed their profile picture. | 12:22:01 |
| justinrestivo changed their display name from oh caml >>= to justinrestivo. | 12:22:30 |
| justinrestivo changed their profile picture. | 12:24:01 |
hpfr | anyone know why umask 077; wg genkey > wg-private gives me Warning: writing to world accessible file. Consider setting the umask to 077 and trying again.? Not sure if NixOS or fish is involved, but this seems to work for everyone on the web | 19:07:09 |
Roos | afair, umask(2) affect's the current process mask. So it should be a shell builtin. | 19:10:18 |
hpfr | hmm, it doesn't seem to work in bash either, even though umask in both fish and bash confirms it's been set to 0077 after umask 077 | 19:16:54 |
hpfr | ahh, I think it was because I had already created the file with different permissions and tried to overwrite without removing. works after removing | 19:18:00 |
Roos | I think some shells (all?) truncate the file if it already exists prior to writing. | 19:18:59 |
hpfr | yeah, but the truncated empty file will still exist with preexisting perms | 19:22:18 |
andi- | I usually have this in every shell config:
set -C # disable clobber
I never want to truncate files silently if they already exist.
| 19:24:36 |
Roos | Cool part about truncate is that applications don't lose the inode nor the fd of they had it open. | 19:28:34 |
hpfr | how costly is it on a laptop's battery to leave a wg link up when you're not really using it? | 19:38:16 |
andi- | almost entirely free | 19:39:12 |
andi- | it is an idle interface that doesn't have any idle chatter | 19:39:20 |
andi- | If you don't send data the interface does nothing. That is one of the design principles behind wireguard. | 19:39:46 |
Roos | I wonder though, if you send packets but the interface can't relay them, how long does it keep them around? | 19:40:57 |
hpfr | cool. I'm using this to remotely access some resources on my home network, is there a way to automatically disable it on my home network? I guess that's what a mesh vpn is for but nebula couldn't handle the cgnat I'm behind | 19:41:16 |
Roos | In reply to @hpfr:matrix.org cool. I'm using this to remotely access some resources on my home network, is there a way to automatically disable it on my home network? I guess that's what a mesh vpn is for but nebula couldn't handle the cgnat I'm behind You could share the ip space, route through your vpn to your home network subnet. | 19:42:07 |
Roos | When you join the network, packets should pick the route without the extra hop. | 19:42:33 |
hpfr | I think that's what I'm doing | 19:42:40 |
andi- | Roos: IIRC it depends on the handshake state. If there was a handshake already it just sends it out. | 19:42:48 |
andi- | Otherwise it tries to do the 0-rtt handshake first which is IIRC 2 packets (including 1 for the payload) | 19:43:10 |
hpfr | if by share the IP space you mean putting my home network subnet in wg's allowedIPs | 19:43:07 |
andi- | A trivial solution to that problem is: Have a high path metric for the VPN route. It will not use that unless you have that same subnet locally in another network. | 19:49:56 |
Roos | In reply to @andi:kack.it Roos: IIRC it depends on the handshake state. If there was a handshake already it just sends it out. Yes, but if connection was lost? (e.g. Plug was pulled) | 19:43:35 |