Das längste Thema

    Zitat von KB19

    Geil, ein Script auf meinem PC fährt unregelmäßig alle paar Stunden mittels DNS einen DoS gegen meinen Router und füllt die Conntrack-Tabelle vollständig?! X(

    Klingt nach einem guten Grund, einen neuen Router zu kaufen? 8o

    Ich würde an dieser Stelle allerdings gerne Probleme tauschen, die Python-Fehlermeldung ModuleNotFoundError: No module named '_ctypes' bei der In­stal­la­tion von mqttwarn lässt nämlich langsam die Barthaare grau werden, weil dieses Problem offensichtlich jedes Jahr mindestens einmal im Internet diskutiert wird und ich mit den beschriebenen/bislang gesichteten Lösungen nichts anfangen kann.

    Meine Präferenz wäre eh' eine gescheite Alternative auf Perl-/Go-Basis (ehrlicherweise: meinetwegen inzwischen auch PowerShell oder ALGOL), aber da bin ich bislang auch nicht fündig geworden…

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Einmal editiert, zuletzt von m_ueberall (6. August 2021 um 09:59)

    Zitat von H6G

    Also bei MS-qttwarn wundert mich das nicht.

    Ja, wo kommt denn das "S" her…? :whistling: (EDIT: Das kommt davon, dass man morgens Nachrichten verfasst, ohne genügend weißen Tee konsumiert zu haben.)

    Zitat von H6G

    In welche Richtung soll er denn ein Notify geben?

    Erste Stoßrichtung ist definitiv Signal (wohl via Verknüpfung mit signal-cli), danach ggf. E-Mail und IRC. Die Sammlung existierender mqttwarn-Plugins gefällt mir als Grundlage eigentlich recht gut, die Nutzerbasis scheint nicht allzu klein zu sein.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    Zitat von m_ueberall

    Erste Stoßrichtung ist definitiv Signal (wohl via Verknüpfung mit signal-cli), danach ggf. E-Mail und IRC. Die Sammlung existierender mqttwarn-Plugins gefällt mir als Grundlage eigentlich recht gut, die Nutzerbasis scheint nicht allzu klein zu sein.

    Reicht es dir, wenn ein entsprechender Daemon ein Executable aufruft mit dir bekannten Aufrufparametern?

    Da kann man dann ein Go-Executable ranhängen, ein Bashscript, oder ein Python Script :P

    Zitat von m_ueberall

    Klingt nach einem guten Grund, einen neuen Router zu kaufen? 8o

    Die Ironie daran: Der ist sogar wirklich schon unterwegs und wartet in Polen darauf, eine Mitfahrgelegenheit in einem freien LKW nach Wien zu bekommen. ^^

    Nein, ernsthaft: Unabhängig von diesem Problem will ich endlich mal testen, wie gut sich eine hochgelobte FRITZ!Box 4040 unter OpenWrt macht.

    Das DNS-Problem muss ich erst genauer untersuchen. Seit das Script deaktiviert ist, ist mal Ruhe…

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Zitat von H6G

    Letzte Version von 2019... https://forum.openwrt.org/t/fritz-box-4040-experiences/64487

    Kenne ich, sollte damit aber kein Problem sein: https://forum.openwrt.org/t/fritz-box-40…riences/64487/5

    21.02.0-rc4 hat theoretisch auch noch ein paar Verbesserungen. Es gibt außerdem ein paar Custom Builds/Patches auf GitHub, die sich bei der 4040 lohnen könnten.

    Bei meinem WNDR3800 bringt "Software Flow Offloading" ebenfalls eine deutliche Performance-Steigerung (x3). Aber der hat halt nur eine Single Core CPU. Der wird alleine schon durch VLAN-Tagging deutlich ausgebremst. Da meine diversen 4/32 (Flash/RAM) Spielgeräte keine aktuelle OpenWrt Version mehr vertragen, wird es sowieso mal Zeit sich neuere Geräte anzusehen. Meine WNDR3800 haben ja auch schon fast 10 Jahre auf dem Buckel. Die dürften gerne zur neuen Spielwiese degradiert werden...

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Nun benötige ich auch mal Unterstützung durch die Schwarmintelligenz. :D

    Von unterwegs aus soll per VPN auf das Heimnetz zugegriffen werden - klappte bisher auch wunderbar.

    Ausgangssituation: Fritzbox 7590 hinter einem FTTH-Modem an einem vollwertigen DualStack-Anschluss der Telekom + Pixel 4a (Android 11). Home-IP über DDNS abrufbar. (nutze sehr zufrieden dynv6.com - myfritz wird nicht genutzt, da der Android-VPN Dienst Probleme mit der IPv6-Adresse hat - also wurde mit dynv6 ein eigener A-Record erzeugt, der nur die IPv4 ausliefert - das klappt auch einwandfrei)

    Problem: das lief eine ganze Weile sehr zuverlässig, neuerdings quittiert das Pixel den Verbindungsaufbau einfach mit "Nicht erfolgreich", was natürlich mega aussagekräftig ist und der Lösungsfindung enorm dienlich ist... :rolleyes:

    Das Kuriose dabei ist:

    - Teste ich es mit denselben Credentials an einem anderen Handy (Nokia 7.1, Android 10) klappt es einwandfrei.

    - Gebe ich dem Pixel statt der DDNS-Adresse die direkte IPv4 mit, klappt es auch!

    Gut dachte ich mir, dann kann das Pixel, aus welchen Gründen auch immer, den Hostnamen nicht auflösen. Aber teste ich es auf dem Pixel in einer termux-Sitzung mit "dig +short ipv4.domain.de" gegen, erhalte ich die korrekte IPv4-Adresse, mit der die Verbindung bei Direkteingabe aufgebaut werden konnte.

    Irgendwelche Ideen woran es liegen könnte? Private DNS ist ebenfalls abgeschaltet auf dem Pixel.

    Es muss ja an irgendeinem Android-Update liegen, schließlich lief das Setup eine ganze Weile so.

    Hab auch schon überlegt mich per logcat ans Pixel zu hängen, aber von den Logs wird man ja auch nur erschlagen.

    Wenn alles nichts nutzt, wirds wohl auf ein Wireguard-Setup hinauslaufen. Bevorzuge aber eigentlich die Fritzbox Lösung, da es ein Setup weniger wäre, um das ich mich selbst kümmern müsste und die VPN-Verbindung nur selten benötigt wird - und hier zuhause laufen schon ohnehin viel zu viele Dienste auf meiner Spielwiese. ^^

    Bin dankbar für jeden Input.

    PS: Hmm... gibt aber auch nicht wirklich ein geeignetes Unterforum für solche netcup-fremden Themen, oder? Naja was solls, dafür haben wir ja das längste Thema. Ach doch, unter sonstiges hätte ich schreiben können... egal, hier im Thema versammeln sich ja alle Geeks. :D

    Guter Tipp frank_m! Ich vergesse immer, dass man an einer Fritzbox auch tcpdumps erstellen kann. :thumbup:

    Ergebnis: Mit der DDNS-Methode scheint der VPN-Aufbau die Fritzbox gar nicht erst zu erreichen, was meine Vermutung, dass das Problem beim Pixel irgendwo liegt, weiter verstärkt.

    Nagut, dann klemme ich mich doch mal per adb ans Pixel, mal sehen ob dort mehr zu erkennen ist.

    Gesagt, getan.

    Logcat mit erfolgreichem VPN-Aufbau per IP:

    Code
    08-06 19:47:44.552  1733  3671 I Vpn     : Switched from [Legacy VPN] to [Legacy VPN]
08-06 19:47:44.552  1733  3671 D Vpn     : setting state=IDLE, reason=prepare
08-06 19:47:44.552  1733  3671 D Vpn     : setting state=CONNECTING, reason=startLegacyVpn
08-06 19:47:44.556  1733 29057 D Vpn     : setting state=CONNECTING, reason=execute
08-06 19:47:45.603  1733 29057 D Vpn     : setting state=CONNECTED, reason=agentConnect
08-06 19:47:51.532  1733  3716 D Vpn     : setting state=DISCONNECTED, reason=agentDisconnect
08-06 19:47:51.547  1733  3716 I Vpn     : Switched from [Legacy VPN] to [Legacy VPN]
08-06 19:47:51.548  1733  3716 D Vpn     : setting state=IDLE, reason=prepare

    Logcat mit erfolglosem VPN-Aufbau per Hostname:

    Code
    08-06 19:48:25.112  1733  6297 I Vpn     : Switched from [Legacy VPN] to [Legacy VPN]
08-06 19:48:25.113  1733  6297 D Vpn     : setting state=IDLE, reason=prepare
08-06 19:48:25.113  1733  6297 D Vpn     : setting state=CONNECTING, reason=startLegacyVpn
08-06 19:48:25.179  1733 29396 D Vpn     : setting state=CONNECTING, reason=execute
08-06 19:48:25.653  1733 29396 D Vpn     : setting state=FAILED, reason=racoon is dead

    Erste kurze Recherche (racoon is dead ... lese ich btw zum ersten mal) ergibt, dass das auf Zertifikatsfehler hindeutet. Natürlich gibt's da kein Zertifikat, ist nur ein DynDNS A-Record.. ich recherchiere mal weiter. X/^^

    Ach sooo, der Waschbär, logisch, ja! Dann wird mir alles klar. 8o

    Welcher Witzbold hat sich nur diese Fehlermeldung in Android ausgedacht. X/^^

    Kurios: beim rumspielen an den Einstellungen "Privates DNS" und "Adaptive Konnektivität" (beides unter Netzwerk & Internet - mal eins, mal beide aktiviert) klappte der VPN-Aufbau ab und zu auch mit dem Hostnamen als Ziel! Aber ohne wirklich Rückschlüsse ziehen zu können, denn das Ergebnis war nie reproduzierbar. Mal klappte es mit einer geänderten Einstellung und im nächsten Moment wieder nicht. Das kann doch nur ein Bug sein. :cursing: