2024-10-22T02:21:28 acidsys not sure if you're online, but i seem to be unable to log into matrix.i.o.o? 2024-10-22T02:42:16 hi Emma, what's the problem 2024-10-22T02:46:03 so, i'm on the vpn, when i try to ssh matrix.i.o.o it "connects" but then gets stuck 2024-10-22T02:46:56 can you ping it? 2024-10-22T02:47:00 also, for some reason connecting to the vpn makes me lose connection to m.o.o, but that's a separate setup thing 2024-10-22T02:47:09 acidsys: ssh _connects_, according to its own verbose logs 2024-10-22T02:48:00 debug1: Connecting to matrix.infra.opensuse.org [...] 2024-10-22T02:48:00 debug1: Connection established. 2024-10-22T02:48:23 (i can ping it just fine) 2024-10-22T02:48:54 can you ssh to some other i.o.o machine (for example thor)? 2024-10-22T02:49:37 both thor and thor1 get stuck at the same stage 2024-10-22T02:49:49 "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY" 2024-10-22T02:51:48 ok, what about tracepath, to check if it's a mtu issue? expected result is https://paste.opensuse.org/pastes/74bd562c97cb 2024-10-22T02:52:14 i cant connect to paste.o.o either while on the vpn 2024-10-22T02:53:02 1?: [LOCALHOST] 0.014ms pmtu 1500 2024-10-22T02:54:14 then I think you have some general problem with the vpn connection (most o.o is routed through the vpn while connected, and generally with no issues) 2024-10-22T02:55:06 what about tracepath to odin.opensuse.org (that will be routed through the internet) ? 2024-10-22T02:55:39 that seems to complete with 17 hops 2024-10-22T02:55:47 what's the pmtu? 2024-10-22T02:55:57 1492 2024-10-22T02:56:32 and i do see a bunch of "asymm" notes in the tracepath output 2024-10-22T02:57:05 ok, that's both quite normal, do you use the udp vpn? 2024-10-22T02:57:26 i dont think i changed that, let me check 2024-10-22T02:58:07 seems so: "proto udp" 2024-10-22T02:58:48 ok, udp/1194 is generally preferred, so that's good, but for testing please try if you have the same issue with tcp/443 2024-10-22T03:00:31 tcp/443 works 2024-10-22T03:00:49 can ssh, can load paste.o.o 2024-10-22T03:04:30 ok, then it's possible you have some firewall or router on the path which does $something to udp packets 2024-10-22T03:05:03 shouldnt be, unless my ISP is doing something weird 2024-10-22T03:12:08 it can be an mtu issue which could be worked around using mssfix in the openvpn configuration, but your output suggests path mtu discovery is working well .. 2024-10-22T03:17:58 to experiment one could do something like `ping -c1 -n -M do -s 1450` and vary the size to see where it caps. both to a host on the internet (like odin.o.o) and internally while connected to the udp vpn 2024-10-22T03:18:54 even with "mssfix 1492", the udp vpn doesnt seem to work 2024-10-22T03:19:43 acidsys: PING odin.opensuse.org (2a07:de40:b27e:1102::a) 1450 data bytes 2024-10-22T03:19:43 ping: local error: message too long, mtu: 1488 2024-10-22T03:19:57 your ping command fails with an error immediately 2024-10-22T03:20:07 Yeah, because 1492 only accounts for the ping overhead. 2024-10-22T03:20:15 I think I had to set mine stupid low. 2024-10-22T03:21:15 Yeah, I had to set it to 1368 2024-10-22T03:21:15 ping -s 1450 fails, seems 1440 is the highest i can go, as 1441 fails aswell 2024-10-22T03:21:35 It's something at the opensuse/suse end. 2024-10-22T03:21:38 Their routers are busted. 2024-10-22T03:21:44 PING odin.opensuse.org (2a07:de40:b27e:1102::a) 1440 data bytes 2024-10-22T03:21:44 1448 bytes from 2a07:de40:b27e:1102::a: icmp_seq=1 ttl=52 time=30.3 ms 2024-10-22T03:22:06 Yeah, but 1440 is just your ping, you need to subtract more off for openvpn + tcp overhead inside the vpn. 2024-10-22T03:22:08 So try 1368 2024-10-22T03:23:01 Firstyear: they have the issue with udp, tcp has less overhead and works 2024-10-22T03:23:03 was already rebuilding when you sent that, "mssfix 1440" _does_ work 2024-10-22T03:23:48 1440 sounds reasonable 2024-10-22T03:23:48 Oh actually, I have mine at mssfix 1296 2024-10-22T03:23:56 acidsys: I had to set 1296 else it drops out 2024-10-22T03:24:03 And corp vpn is 1368 2024-10-22T03:24:25 I think I had to do ipv6 only too, because v4 was totally busted. 2024-10-22T03:24:46 well you shouldn't use legacy IP anyways :) 2024-10-22T03:24:46 1440 was the highest value i could go in ping, so something about MTUs is busted even if detection seems to work fine 2024-10-22T03:25:23 ah, looked at openvpn logs, seems that was setting up the vpn at 1500 mtu before 2024-10-22T03:25:36 "openvpn[1126326]: net_iface_mtu_set: mtu 1500 for tun0" 2024-10-22T03:25:37 tun-mtu is 1500 by default 2024-10-22T03:25:42 acidsys: It's because v4 to corp networks are wildly broken. 2024-10-22T03:25:53 But then v6 has it's own issues because ibs shits itself on the reg and doesn't do v6 2024-10-22T03:26:04 Anyway, lots of issues there. 2024-10-22T03:26:27 I can't speak for corporate, but if you say we have an issue at openSUSE, then please tell me what I should do. so far you are the only two people I hear of having this issue 2024-10-22T03:26:27 acidsys: im still using v4-only on my server because v6 as a whole is busted :') 2024-10-22T03:26:37 I'll mail you about it. 2024-10-22T03:26:50 I've reported it before and got "less than helpful" responses. 2024-10-22T03:26:56 Most of the aussies just ask me for help at this point. 2024-10-22T03:27:31 acidsys: realistically, the server needs to push an mssfix by default. 2024-10-22T03:27:51 mssfix should be a client side workaround, for users which can do without mssfix, they should not use it 2024-10-22T03:28:05 ^ I think that's what I got told last time about corp vpn too :) 2024-10-22T03:28:08 honestly it could be my kernel flags, but i havent had issues with other things before, so setting mssfix on my end sounds reasonable 2024-10-22T03:28:11 and is why I stopped reporting the issues 2024-10-22T03:28:19 It won't be kernel. 2024-10-22T03:28:24 It affects me and others Emma [it/its] 2024-10-22T03:28:37 whom in openSUSE does it affect? 2024-10-22T03:28:56 openVPn docs clearly say that mssfix is for when there are issues with path mtu discovery 2024-10-22T03:29:01 if pmtud works, then we should not push mssfix 2024-10-22T03:29:22 additionally, its odd that everything worked fine the first time, but doesnt now 2024-10-22T03:29:24 acidsys: At one point a few years back I traced it down to a router in suse 2024-10-22T03:29:41 pmtu isn't working though :) 2024-10-22T03:29:45 I'm rather sure that router long doesn't exist anymore 2024-10-22T03:29:58 Yeah, probably not. 2024-10-22T03:29:58 it's working for me and emma going by tracepath 2024-10-22T03:30:33 For v6 yes, 2024-10-22T03:30:42 that should be sufficient 2024-10-22T03:33:41 that reminds me, i only have my kernel flags set for v4 lol 2024-10-22T03:34:08 Emma: it's possible the route over the internet changed ISP side and only some routers on the path have the issue 2024-10-22T03:34:29 hm, that would make sense, yeah 2024-10-22T03:35:02 And the further you are away, the more exposed you are to that :) 2024-10-22T03:37:52 time for static routing :P (/j) 2024-10-22T03:38:44 lmao 2024-10-22T03:43:29 tcp over avian carrier 2024-10-22T03:50:37 I'm rather disappointed noone ported IPoAC to IPoCC (crab carrier) yet 2024-10-22T03:50:52 lmao 2024-10-22T03:52:08 your packets would get corroded by the salt i'd think :p 2024-10-22T03:53:07 electronics dont like salt water very much 2024-10-22T03:53:34 right, could get too rust-y 2024-10-22T03:54:13 besides, dont crabs like, not go very far? xD 2024-10-22T03:56:07 that's what IPoACC (avian crab carrier) is for, the pigeon takes the crab over longer distances 2024-10-22T03:57:31 xD 2024-10-22T07:04:06 *** teepee_ is now known as teepee 2024-10-22T10:58:36 *** teepee_ is now known as teepee 2024-10-22T16:24:41 *** teepee_ is now known as teepee 2024-10-22T18:53:38 has firstyear fallen over again lol 2024-10-22T23:42:48 *** teepee_ is now known as teepee