2026-07-21T10:13:43+02:00 https://nostr.ae Freifunk Karlsruhe https://nostr.ae/npub15v4lkgrm7j684npdh2udfj8e38u0pzzj3c6ylph3nkxeju5az72qwcchpl https://assets.chaos.social/accounts/avatars/109/819/387/769/970/593/original/44ce152bcaa43cd1.png https://assets.chaos.social/accounts/avatars/109/819/387/769/970/593/original/44ce152bcaa43cd1.png https://nostr.ae/nevent1qqsfrft395tjppxx9p5hqxyfzvlukjsml5vcdvah9lultqvftjzlavgzyz3jh7eq006tg7kv9kat34xglxyl3uyg228rgnux7xwcmxtjn5tegvejgd5 In reply to <a href='/nevent1qqsr29ueeda6ua558cgxcw6x4lw6syyzvh98ly7gsa3hwmfhe9cjc5spf23nu'>nevent1q…23nu</a><br/>_________________________<br/><br/>Die Logik basiert auf der in Gluon eingebauten Idee das es zwei Quellen für die RAs gibt. Einmal der Knoten selber, damit es auch ohne Internet immer die Möglichkeit auf Lokale Kommunikation gibt.<br/>Die anderen RAs kommen dann von unserem Gateway und haben dementsprechend auch eine default Route. 2026-01-19T23:19:57+01:00 https://nostr.ae/nevent1qqspqgm5lp59wl0mfzmpx6jj0pflt7w2q45k6vnjvg03yxz8mh49vzszyz3jh7eq006tg7kv9kat34xglxyl3uyg228rgnux7xwcmxtjn5tegkqhkr0 In reply to <a href='/nevent1qqst8p5y25waj3k7etxs4mrdlxgdj6hg0fkq9swt0cljrm9g9h29vvszk7546'>nevent1q…7546</a><br/>_________________________<br/><br/>Wir konnten gestern Abend endlich das Problem finden.<br/><br/>Der Autoupdater auf die Beta (und der Autoupdater der Experimental.) gehen endlich wieder. 2026-01-19T08:23:04+01:00 https://nostr.ae/nevent1qqs8nlenptkkjlw2frzt7ap2wsfwuzcu9skc9yrtsy9ylmu4dtwr3wczyz3jh7eq006tg7kv9kat34xglxyl3uyg228rgnux7xwcmxtjn5teg78zzh4 In reply to <a href='/nevent1qqsvd3h2t2terrvxn9z9lgsqgdwwehjjgjtg5gggceejf358md39z6q3z4qw3'>nevent1q…4qw3</a><br/>_________________________<br/><br/>Ja wir wissen das die MTU Niedrig ist. Vorher war die MTU 1348, was eine Zahl war bei der mehrere CLAT auf Android aus dem Tritt gekommen sind, und konsequent 20 Byte zu große Pakete versucht haben zu senden. Dadurch das wir nun 1280 als MTU setzen, scheint sich das Problem lösen zu lassen.<br/>Gerne würden wir die MTU wieder vergrößern.<br/><br/>Welche DHCP-108 Zeitspanne wäre denn ein Üblicher Erwartungswert? Wir haben diesen Wert aus der IPv6 Mostly Demo der Ruhr Uni übernommen gehabt. 2026-01-17T18:14:17+01:00 https://nostr.ae/nevent1qqs22lthpaz6n87ecqpw9cvzwr5ty7n87xx65rrqzm4pufvfpgcvc4gzyz3jh7eq006tg7kv9kat34xglxyl3uyg228rgnux7xwcmxtjn5tegk4fx8m In reply to <a href='/nevent1qqs2vq0pldjs8hhnyad7qtxqktq0pmjlp2scsxtn8ff0039jzulyjysajw677'>nevent1q…w677</a><br/>_________________________<br/><br/>Feedback ist immer willkommen. <br/><br/>Das “Problem” an der Stelle ist der Resolver-Cache auf dem Knoten selber. Dein Node hat noch unsere aktuelle Stable Version aus 2025, bevor das v6 Mostly gestartet ist.<br/>Da fragt der Cache noch die non-DNS64 Server.<br/><br/>Wir haben das zwar “hintendrum”umgebogen, aber bei neuen Knoten dauert es eine weile bis es greift. Du kannst aber Firmware ab Version 0.15.0 testen, da ist der default dann die DNS64 Server. 2026-01-17T18:07:33+01:00 https://nostr.ae/nevent1qqsds8lpke62n0zshys6q49dhwkp56jmehr9g3phcpm2zc6xvaj5ycczyz3jh7eq006tg7kv9kat34xglxyl3uyg228rgnux7xwcmxtjn5tegqv2w8g Nachdem unser IPv6-Mostly Setup endlich halbwegs rund läuft, sind unsere NAT64 Server regelmäßig ans Limit der möglichen Verbindungen gekommen, die sie übersetzten können.<br/><br/>Wir haben deswegen noch, pro Server, 8 weitere IPv4 Adressen in unseren Pool geholt. <br/>Da diese Adressen exklusiv für das das NAT64 sind, steigt die Kapazität auf fast das 10-fache.<br/><br/>So ist auch Stoßzeiten nun mehr als genug Luft nach oben und ihr könnt ohne Probleme weiter surfen!<br/><br/>#IPv6mostily #ipv6 #nat64 2026-01-16T13:55:34+01:00