Conversation

Notices

1. Embed this notice
   johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:05 JST Johann150

   in reply to

   • sn0w :ad:

   @sn0w@cofe.rocks aaah :neofox_cry_loud: what now

   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     sn0w :ad: (sn0w@cofe.rocks)'s status on Wednesday, 24-Jan-2024 04:30:06 JST sn0w :ad:

     in reply to
     @Johann150 :smugdance: :smugdance: :smugdance: :smugdance: :smugdance: :smugdance: :smugdance: :smugdance: :smugdance: :smugdance:
   • Embed this notice
     johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:08 JST Johann150

     in reply to

     • sn0w :ad:

     @sn0w@cofe.rocks
     :neofox_reject: checking if it uses IPv6 by doing some shenanigans
     :neofox_approve: checking if it uses IPv6 by seeing if cofe.rocks emoji work again
     
     i'm happy to report that cofe.rocks emojis are in fact working again :neofox_owo:
     
     https://akkoma.dev/FoundKeyGang/FoundKey/commit/83bce626724801e330a0fef30db9eeadbcd3363f

   • Embed this notice
     sn0w :ad: (sn0w@cofe.rocks)'s status on Wednesday, 24-Jan-2024 04:30:10 JST sn0w :ad:

     in reply to
     @Johann150 :nadeshikoStronk: progress
   • Embed this notice
     johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:11 JST Johann150

     in reply to

     • sn0w :ad:

     @sn0w@cofe.rocks so after looking at different docs for a bit i think i can still force it to prefer v6 addresses by settting some options. If hints.ai_flags specifies the AI_V4MAPPED flag, and hints.ai_family was specified as AF_INET6, and no matching IPv6 addresses could be found, then return IPv4-mapped IPv6 addresses in the list pointed to by res.If you are wondering about the strange wording, thats because this is from man 3 getaddrinfo :neofox_blep:
     
     So the plan is: Tell it that I only want v6 addresses, but if it really has to its okay if it gives me IPv4 addresses mapped to IPv6 address space (like ::ffff:127.0.0.1). Trying it out gives the expected result:
     cache.lookup("cache.cofe.rocks", { family: 6, hints: dns.V4MAPPED }, console.log)givesnull 2605:6400:30:f2ff:c0fe::41 6 1706033308991 63
     and this also still workscache.lookup("github.com", { family: 6, hints: dns.V4MAPPED }, console.log)givingnull ::ffff:140.82.121.4 6 1706033385512 60

   • Embed this notice
     sn0w :ad: (sn0w@cofe.rocks)'s status on Wednesday, 24-Jan-2024 04:30:13 JST sn0w :ad:

     in reply to
     @Johann150 wild, it seems they had a bug about A/AAAA fallback a while ago but the way they fixed it is "v6 if v4 fails", not the other way around
     
     https://github.com/szmarczak/cacheable-lookup/issues/27
     https://github.com/szmarczak/cacheable-lookup/commit/b2348d5aede36bdf625eba2aa17ca4dedb74c62b
     
     javascript community pls
   • Embed this notice
     johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:14 JST Johann150

     in reply to

     • sn0w :ad:

     @sn0w@cofe.rocks okay the plot thickens. i'm not done refactoring yet but i noticed that the package cacheable-lookup is used for DNS queries. and now look at this:
     // thats how you import an EcmaScript module on the node command line 🥴 let CacheableLookup = await import('cacheable-lookup').then(x => x.default); // this uses the same options as Foundkey uses cache = new CacheableLookup({ maxTtl: 3600, // 1h errorTtl: 30, // 30sec lookup: false, // no fallback if the server returns ENOTFOUND }); // using console.log as a callback so i can see the result cache.lookup("cache.cofe.rocks", console.log)
     and the output I get is:null 107.189.12.41 4 1706030521656 7281st argument is an error if any, so no error
     2nd is the resulting address, which is IPv4 in this case.
     3rd is the result address family, again v4
     and then probably some TTLs or something
     
     If using nodejs's builtin DNS resolver (which doesnt do caching):dns.lookup('cache.cofe.rocks', console.log);which givesnull 2605:6400:30:f2ff:c0fe::41 6i.e. it gives a v6 address. huh?

   • Embed this notice
     johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:15 JST Johann150

     in reply to

     • sn0w :ad:

     @sn0w@cofe.rocks :neofox_thonk: it uses the got package, maybe some weird default configuration in there.
     
     i wonder why that package is used in the first place since nodejs has its own function to download a URL :neofox_thonk:
     
     i think i'll refactor that :neofox_googly_shocked:

   • Embed this notice
     sn0w :ad: (sn0w@cofe.rocks)'s status on Wednesday, 24-Jan-2024 04:30:16 JST sn0w :ad:

     in reply to
     @Johann150 lmk what you find i'm curious now :neocat_googly:
   • Embed this notice
     johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:17 JST Johann150

     in reply to

     • sn0w :ad:

     @sn0w@cofe.rocks i mean the proxy is inside foundkey so i need to check on my side :neofox_think_googly:

   • Embed this notice
     sn0w :ad: (sn0w@cofe.rocks)'s status on Wednesday, 24-Jan-2024 04:30:18 JST sn0w :ad:

     in reply to
     @Johann150 maybe because it's a redirect?
     it will hit ::119 first and then get a 302 towards the cache at ::41
     should work ig though, at least seems to for others
   • Embed this notice
     johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:20 JST Johann150

     in reply to

     • sn0w :ad:

     @sn0w@cofe.rocks really the solution is for the proxy to use IPv6 :neofox_thonk: not sure why...

   • Embed this notice
     sn0w :ad: (sn0w@cofe.rocks)'s status on Wednesday, 24-Jan-2024 04:30:22 JST sn0w :ad:

     in reply to
     @Johann150 it could be that routing to path.net broke for some reason
     my v4 space is from there while v6 goes directly to the frantech AS
     unfortunately buyvm don't offer additional v4 IPs without "DDoS protection"
     so reachability disagreements like this can sometimes happen
   • Embed this notice
     johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:23 JST Johann150

     in reply to

     • sn0w :ad:

     @sn0w@cofe.rocks funny enough ping over IPv6 works :neofox_peek:
     $ ping cache.cofe.rocks PING cache.cofe.rocks(takina.woem.moe (2605:6400:30:f2ff:c0fe::41)) 56 data bytes 64 bytes from takina.woem.moe (2605:6400:30:f2ff:c0fe::41): icmp_seq=1 ttl=55 time=19.5 ms

   • Embed this notice
     sn0w :ad: (sn0w@cofe.rocks)'s status on Wednesday, 24-Jan-2024 04:30:24 JST sn0w :ad:

     in reply to
     @Johann150 could be a hetzner outage
     i just tried doing a globalping (https://www.jsdelivr.com/globalping) and their hetzner node has the same 100.64.10.22 problem as you while the others work
   • Embed this notice
     johann150@genau.qwertqwefsday.eu's status on Wednesday, 24-Jan-2024 04:30:26 JST Johann150

     • sn0w :ad:

     @sn0w@cofe.rocks emoji from your instance are broken on my side. emoji itself works fine when i go to the URL manually. but misskey/foundkey normally proxies the emoji request. and for some reason my server can't reach yours (i.e. cache.cofe.rocks)
     
     (even worse it only tries using IPv4, not sure why)
     $ ping -4 cache.cofe.rocks PING (107.189.12.41) 56(84) bytes of data. From 100.64.10.22 (100.64.10.22) icmp_seq=1 Destination Host Unreachable