| 29 May 2021 |
 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 |
| Roos | But you can have multiple routing tables which will be sequentially scanned and matched, just like normal routes. | 19:58:43 |
|  delroth joined the room. | 20:00:03 |
| Roos | See `ip-rule` | 19:58:55 |
