Man kann einen DNS, der einem beliebt, konfigurieren. ZB den eigenen. Oder vom Provider. Zudem wird bei DHCP ein DNS mitgeschickt. Ich würde da jetzt nicht drauf wetten, dass eine kocobox den übernimmt und den google rauswirft, da wir keine box mit dhcp konfiguriert lassen, aber halte es für recht wahrscheinlich. Vielleicht hat einer der Kollegen hier ja Erfahrung damit.
Allerdings hätte ich auch einen eigenen DNS beimn Hersteller zB begrüßt.
Zitat von 22sam72 im Beitrag #15Leider war das Eintragen der fehlenden DNS bei uns nicht die Lösung.Auch die Anpassung des UDP-Agings bringt keine Verbesserung.
Finde ich plausibel, wenn auch blöd.
Wie sieht es denn aus mit der MTU mal probeweise? Irgendwo auf der anderen Seite des Tunnels wird es ja was geben, dem mal mal ein Paketchen schicken kann ohne großen Aufwand. Dann mit der payload spielen und mal schauen, ob kleine Pakete zur Zeit des Aussetzers unfragmentiert durchgehen und dann eben immer größer werden, bis es nicht mehr geht. Ganz nur Not halt mal MTU vom Konnektor noch bisschen runterdrehen und schauen, ob's dann besser klappt.
Auch wenn eiiigentlich, so wie ich das Lacon-Handbuch verstehe , ohne die Bevorzugung nix mehr rumgeschraubt werden sollte. Und es sollte auch noch noch passen mit der Größe bei den genannten MTUs. Warum ist die MTU im LAN nur auf 1300? Achja: Wenn da v4 in v6 verpackt wird, könnte es dann doch nochmal knapp werden (muss nachschauen,w as dafür nochmal drauf geht). Kann es sowas sein?
Oder halt wireshark dazwischenhängen und schauen, ob einem das was bringt. Ein timeout klingt ja schon sehr verdächtig.
jetzt nach 6 Monaten möchte hier kurz die Lösung unseres Problem mitteilen:
Letztendlich war die Firewall im LANCOM-Router die Ursache. Hier war eine Regel eingetragen, die das Telefonverhalten (QoS) verbessern sollte.
Offenbar hat diese aber wohl Einfluss auf die MTU gehabt und für einen instabilen Datentransfer gesorgt.
Da "bei uns" Firewall-Einstellungen offenbar erst mit ca. 10 Minuten Verzögerung Wirkung zeigen, hatte ein kurzes deaktivieren der Firewall bisher nicht die Lösung gebracht.
Erst ein längeres unbeabsichtigtes Abschalten der Firewall brachte dann die Lösung.
Regel deaktiviert >> 15 Minuten warten >> Problem gelöst
Trotzdem danke für die Unterstützung hier im Forum.
v.G.
4 Mitglieder finden das Top!
2 Mitglieder haben sich bedankt!
habe diesen Thread interessiert gelesen. Haben auch eine LANCOM-Firewall, KIM (eAB, eAU, E-Rezept, VZD) funktioniert an sich, das Verschicken einer KIM-Nachricht dauert aber ca. 20+ Sekunden. Könnte das auch etwas mit den hier beschriebenen Problemen zu tun haben? Oder ist eine solche Zeitdauer normal?
ich kann nicht sagen, ob es was damit zu tun hat, aber 20+ Sekunden für eine KIM-Nachricht ist definitiv zu lang, sofern: * keine großen Anhänge dran sind * die Anzahl der Empfänger gering ist
Diese beiden Aspekte treiben sonst wegen Verschlüsselung und Signaturen den Zeitbedarf des Konnektors vor dem reinen Versandzeitpunkt in die Höhe. Mit einer reinen Textnachricht an einen Empfänger probieren. Sollte eigentlich unter 10 Sek. dauern (ich denke sogar eher unter 5 Sek.)