| 29 May 2021 |
 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 |
| Roos | In reply to @hpfr:matrix.org
if by share the IP space you mean putting my home network subnet in wg's allowedIPs Yes. | 19:43:59 |
| Roos | In reply to @roosemberth:orbstheorem.ch
Yes, but if connection was lost? (e.g. Plug was pulled) I'm asking because when you roam, no packets are lost. | 19:44:30 |
| Roos | So there must be a buffer somewhere. | 19:44:38 |
| hpfr | In reply to @roosemberth:orbstheorem.ch
When you join the network, packets should pick the route without the extra hop. how do the packets "know" about both routes? I would have thought putting a range in wg's allowedIPs sort of claims them | 19:55:35 |
| andi- | In reply to @roosemberth:orbstheorem.ch
I'm asking because when you roam, no packets are lost. It will just reconnect again with the next packet. | 19:57:57 |
| Roos | First matching route is used | 19:57:21 |
| andi- | Packets are authenticated via their keys and not their source addresses. If you send packets 50/50 from different source addresses that works just fine. You can expect to receive packets from the other side on both as well.. | 19:58:47 |
| Roos | I'm not sure the path metric is used by Linux though | 19:57:50 |
