Seit Dienstag kein eRezept/eAU

[VOSUE]

Seit Dienstag keine eAu/Rezept- alles Grün, Karten können eingelesen werden. Mehrmals Neustart Coco Box und Server. Bd eHBA noch gültig bis 15.6, Status leuchtet rot, hat jemand einen Tipp
Danke Vosue

[Doc76]

Lesegeräte in denen sich die eHBA's befinden auch neu gestartet? Dies hilft bei uns in Verbindung mit Coco Box Neustart.

[VOSUE]

Ja auch neu gestartet

[M. Braun]

Moin,

aus dem Verzeichnis Turbomed/Programm/communicator/Plugins alle Ordner gelöscht? Hilft sehr oft.

VG M. Braun

[DC19]

Können Sie den eARZT Briefe empfangen, um die Ursache etwas einschränken zu können.... Wenn nicht stimmt vielleicht was mit dem KIM Dienst nicht, KIM Konfiguration, Update auf KIM 1.5. Kokobox Update (Gab doch vor einer Zeit eine Mitteilung: wenn kein Update erfolgt wird man zwangsgetrennt). KIm Adresse neu Registrieren.

[FortiSecond]

Konnektor: De-Registrieren, Re-registrieren (Contract-ID notieren!). Manchmal hilft das bei den seltsamsten Dingen.

[PC Fuzzy]

Solch ein Problem hatte ich vor zwei Wochen. Von heute auf morgen ging die TI nicht. eAU, eRezepte und Kim von KV.dox, nichts, aber die Karten liessen sich einlesen. TM zeigte alles grün an. Ich habe auch alles runtergefahren, neu gestartet, eben halt die routinemäßige Prozedur. Nachdem nichts half und ich mir keinen Rat wusste, bei TM Hotline angerufen und die haben den MTU Wert vom Server und der KocoBox geändert und zwar von 1500 Byte auf 1400 Byte. Danach funktionierte wieder alles. Wieso, weshalb, warum konnte mir keiner erklären.
MfG PC Fuzzy

[FortiSecond]

Solch ein Problem hatte ich vor zwei Wochen. Von heute auf morgen ging die TI nicht. eAU, eRezepte und Kim von KV.dox, nichts, aber die Karten liessen sich einlesen. TM zeigte alles grün an. Ich habe auch alles runtergefahren, neu gestartet, eben halt die routinemäßige Prozedur. Nachdem nichts half und ich mir keinen Rat wusste, bei TM Hotline angerufen und die haben den MTU Wert vom Server und der KocoBox geändert und zwar von 1500 Byte auf 1400 Byte. Danach funktionierte wieder alles. Wieso, weshalb, warum konnte mir keiner erklären.
MfG PC Fuzzy

Schön, dass es damit klappt. Ein wertvoller Hinweis.
Andererseits finde ich es außerordentlich bedenklich, im LAN mit der MTU zu spielen und dann insbesondere nur am Server runterzugehen. Uneinheitliche MTU-Werte führen immer zu etwas mehr Overhead, weil die Gegenstellen sich abstimmen müssen. Dazu kommt, dass kleinere MTU bei größeren Datenblöcken zu mehr Paketen und damit mehr Overhead führen. Es kostet also ein wenig Performance.
Da erscheint es mir sinnvoller, wenn NUR am Konnektor die MTU gesenkt wird (warum auch immer!). Denn der Server wird sich beim Datenaustausch mit dem Konnektor an diesen anpassen, denn es ist sehr wahrscheinlich, dass er alle relevanten Standards und Fähigkeiten mitbringt. Der Server, wohlgemerkt. *hust*

[PC Fuzzy]

@FortiSecond, ich stimme ihnen zu. Unterschiedliche
MTU Werten an einzelnen Clients, erhöhen die Overhead Werte. Deswegen habe ich an allen Clients die MTU Werte auf 1400 Byte geändert. Was die Performance betrifft, so habe ich im Augenblick kein Unterschied festgestellt. Testweise habe ich heute die MTU Werte von Server und Clients auf den Standardwert von 1500 Byte gestellt und die Kocobox auf 1400 Byte belassen. eAU und Kim funktionierten, allerdings kein eRezept. Alles wieder einheitlich auf 1400 Byte gestellt und es funktioniert. Es gab keine Updates von TM oder Windows und von heute auf morgen waren die Datenpakete zu gross. Verstehe ich nicht.
MfG PC Fuzzy

[INP]

Die MTU ist nur im lokalen Netz normalerweise 1500. Schon an einen normalen DSL-Anschluss ist die MTU 1492, zum Teil auch 1484. Daten die durch die Koco Box gehen werden verschlüsselt. Da entsteht dann noch weiterer Overhead. Die MTU dürft dann bei 1400 – 1420 liegen. Auch ist nicht gesagt das eine Teilstrecke im Internet einen noch geringere MTU hat.

Normalerweise wird die MTU im Hintergrund ausgehandelt (Stichwort: MSS Clamping). Wenn das nicht mehr funktioniert, ist irgendwas im Netz (Internet) nicht richtig konfiguriert und gibt keine Meldung zurück, dass das Paket zu groß ist. Die MTU fest einzustellen ist normalerweise keine gute Idee, besser man sucht den Fehler. Mit der MTU Größe zu experimentieren, ist eigentlich nur zur Fehlersuche zu empfehlen.

Auch möglich, das Ziel ist plötzlich via IPv6 erreichbar, dann wird meist IPv6 bevorzugt. Nur hat IPv6 mehr Overhead als IPv4 und die MSS sinkt.

Jens

[Olli]

Moin,
wir sind weiterhin auf Fehlersuche. Die MTU von 1400 sah im ersten Augenblick gut aus, aber tatsächlich hat es auch nicht die Lösung gebracht.
Hat jemand eine Idee, ob das "normal" im Sinne von der TI ist: Diese Fehlermeldung steht in der Kocobox unter "Fachmodul ePA" Telematikdienste, dort sind alle Dienste nicht erreichbar und laufen in ein Timeout.
Bei KIM sind nun die eingebenenen Daten angeblich ungültig oder nicht erreichbar.
"Die Anmeldung in das KIM Client Modul war nicht erfolgreich Fehlertext: 3007 - Die angegebenen Credentials sind nicht gültig oder falsch."

Vielleicht hängt das alles zusammen?

[FortiSecond]

Moin,
wir sind weiterhin auf Fehlersuche. Die MTU von 1400 sah im ersten Augenblick gut aus, aber tatsächlich hat es auch nicht die Lösung gebracht.
Hat jemand eine Idee, ob das "normal" im Sinne von der TI ist: Diese Fehlermeldung steht in der Kocobox unter "Fachmodul ePA" Telematikdienste, dort sind alle Dienste nicht erreichbar und laufen in ein Timeout.
Bei KIM sind nun die eingebenenen Daten angeblich ungültig oder nicht erreichbar.
"Die Anmeldung in das KIM Client Modul war nicht erfolgreich Fehlertext: 3007 - Die angegebenen Credentials sind nicht gültig oder falsch."

Vielleicht hängt das alles zusammen?

Wann wurde SMC-B getauscht? Wäre der alte Praxisausweis jüngst abgelaufen?

Unabhängig davon schadet es nicht, die Registrierung am VPN-Zugangsdienst zu erneuern. 2 x (erst RSA, dann ECC - falls Auswahl angeboten wird).
Wenn es sich um den "Standardfehler" handelt, klappt das ohne vorherige De-Registrierung. Wenn es der Standardfehler ist, dürfte danach innerhalb von Minuten alles fein sein (Telematik-ID korrekt mit der aktuellen SMC-B verknüpft).

Eventuell hat es Sinn, eine CGM-KIM-Adresse ebenfalls erneut zu registrieren (Telematik-ID). Da gab es schon merkwürdige Zufälle zum Ablaufdatum eines für die Registrierung genutzten Praxisausweises. Und auch komplette Account-Löschung zum Ende einer Kündigungsfrist für den Konnektor (nicht KIM!) - aber das ist zum Glück per Anruf bei Hotline reversibel.

ePA: Kann ein Folgefehler sein.
By the way: Ist die Konnektorversion aktuell? Sicherheitshalber nachsehen. Mit der alten Version kann der Zugriff auf die ePA erschwert/unmöglich sein.

[Olli]

Moin Forti,
die SMC-B wurde letztes Jahr zusammen mit der Kocobox getauscht, die HBA laufen Mitte Juni aus, also von den Zertifikaten her sollte alles in Ordnung sein. Die HBA wurden nun heute auch getauscht und aktiviert, führte aber auch zu keiner Verbesserung. KIM ist auf die SMB-C Registriert.

KIM hält sich ewig mit "Laden verfügbare Karten" auf in Turbomed, davor kam wieder die Fehlermeldung mit den Credentials.
Zusätzlich hab ich über das KIM Dashboard eine Fehlermeldung beim Test der Netzwerkroute, dass keine Verbindung zur Telematikinfrastruktur aufgebaut werden konnte 100.102.0.0 - die Route ist am Server, in der FW usw aber gesetzt und es gab bei uns keine Änderungen / Updates seit Fehlerbeginn...
Mit der KIM Adresse kann ich mich nicht einloggen, der Account Manager sei nicht erreichbar.
Somit kann ich hier auch nichts deregistrieren.

Die Deregistrierung und Registrierung der VPN Verbindung hab ich durchgeführt, es steht nun ein aktuelles Datum dort, aber es geht weiterhin nicht.
Die Route habe ich am Server gelöscht und neu hinterlegt, aber das brauchte leider auch nichts.

Zwischen Internet und Kocobox ist die Fritzbox fürs Internet und die Fortigate fürs PraxisLAN da. Im Logfile sieht man auc aufgebaute Verbindungen des VPN der Koco...
Statische Routen sind in der Fortigate und sogar lokal am Server und den Arbeitsplätzen hinterlegt... Ich bin gerade etwas ratlos, wo der Fehler liegt

VG
Olli

[Doktorfisch]

Solch ein Problem hatte ich vor zwei Wochen. Von heute auf morgen ging die TI nicht. eAU, eRezepte und Kim von KV.dox, nichts, aber die Karten liessen sich einlesen. TM zeigte alles grün an. Ich habe auch alles runtergefahren, neu gestartet, eben halt die routinemäßige Prozedur. Nachdem nichts half und ich mir keinen Rat wusste, bei TM Hotline angerufen und die haben den MTU Wert vom Server und der KocoBox geändert und zwar von 1500 Byte auf 1400 Byte. Danach funktionierte wieder alles. Wieso, weshalb, warum konnte mir keiner erklären.
MfG PC Fuzzy

Wir hatten seit letzter Woche bei uns auch dasselbe Problem. Letztendlich hat bei uns erst das Umstellen des MTU-Werts durch den TM-Support von 1500 auf 1400 an ALLEN Arbeitsplätzen (Clients wie Server) zur Lösung geführt.
Hierzu muss man über den Command-Prompt (Windows Eingabeaufforderung muss mit Admin-Rechte gestartet werden) händisch an allen Rechnern den MTU-Wert von 1500 auf 1400 reduzieren.

Dazu über CMD folgendes Commando zur Abfrage eingeben:
netsh interface ip4 showinterfaces

Zum Umstellen folgendes Commando eingeben:
netsh interface ip4 set subinterface "X" mtu =1400 store=persistent wobei X für den Zahlenwert des jeweiligen aktiven LAN-Anschluss des Arbeitsplatzes steht, welchen man über die vorherige Abfrage erfährt.

Hier ein Screenshot, auf dem die Abfrage und die Änderungseingaben ersichtlich sind:

Screenshot_20250526_210337_Gallery.jpg

Laut Turbomed-Support ein neu aufgetretenes Problem, wenn Vodafone der Internet/Telefonanschluss-Anbieter ist.

Angeblich hätte Vodafone irgendetwas geändert. Das Problem (und die Problemlösung) beträfe wohl ausschliesslich Turbomed-Anwender mit Vodafone-Telefon/Internet-Anschluss.

Weiterhin dürfen die relevanten Dienste in der Firewahl nicht blockiert werden. Und die entsprechenden Dienste (HCS.CBOX.DE und CGM IDP Service) müssen auf dem Server gestartet sein.

Zu guter Letzt musste der Server noch einmal komplett neu gestartet werden, dann lief alles wieder (ePA, eAU und eRP).

Insgesamt eine Aktion von 2,5h TM-Technikereinsatz.

Kollegiale Grüsse,
Doktorfisch.

[Olli]

Wir hatten seit letzter Woche bei uns auch dasselbe Problem. Letztendlich hat bei uns erst das Umstellen des MTU-Werts durch den TM-Support von 1500 auf 1400 an ALLEN Arbeitsplätzen (Clients wie Server) zur Lösung geführt.
Hierzu muss man über den Command-Prompt händisch an allen Rechnern den MTU-Wert von 1500 auf 1400 reduzieren.

Laut Turbomed-Support ein neu aufgetretenes Problem, wenn Vodafone der Internet/Telefonanschluss-Anbieter ist.

Angeblich hätte Vodafone irgendetwas geändert. Das Problem (und die Problemlösung) beträfe wohl ausschliesslich Turbomed-Anwender mit Vodafone-Telefon/Internet-Anschluss.

Kollegiale Grüsse,
Doktorfisch.

Moin Doktorfisch,

können Sie uns sagen, ob es sich dabei um Vodafone DSL oder Vodafone Kabelanschlüsse handelt? Bei Kabel und DualStack gab es ja schon öfter mal Probleme. Wir haben einen Business DSL mit fester IPv4. Und mal eben komplett die MTU zu ändern, weil es mal wieder ein “unerklärliches” Verhalten der CGM TI gibt ist echt anstrengend und frustrierend VF wirds auf TM schieben und andersherum…

VG Olli

[Doktorfisch]

Wir hatten seit letzter Woche bei uns auch dasselbe Problem. Letztendlich hat bei uns erst das Umstellen des MTU-Werts durch den TM-Support von 1500 auf 1400 an ALLEN Arbeitsplätzen (Clients wie Server) zur Lösung geführt.
Hierzu muss man über den Command-Prompt händisch an allen Rechnern den MTU-Wert von 1500 auf 1400 reduzieren.

Laut Turbomed-Support ein neu aufgetretenes Problem, wenn Vodafone der Internet/Telefonanschluss-Anbieter ist.

Angeblich hätte Vodafone irgendetwas geändert. Das Problem (und die Problemlösung) beträfe wohl ausschliesslich Turbomed-Anwender mit Vodafone-Telefon/Internet-Anschluss.

Kollegiale Grüsse,
Doktorfisch.

Moin Doktorfisch,

können Sie uns sagen, ob es sich dabei um Vodafone DSL oder Vodafone Kabelanschlüsse handelt? Bei Kabel und DualStack gab es ja schon öfter mal Probleme. Wir haben einen Business DSL mit fester IPv4. Und mal eben komplett die MTU zu ändern, weil es mal wieder ein “unerklärliches” Verhalten der CGM TI gibt ist echt anstrengend und frustrierend VF wirds auf TM schieben und andersherum…

VG Olli

@Olli
Wir haben einen Vodafone Business-DSL-Anschluss (soweit ich weiss mit fixer IP-Adresse) der damals 2022 auf IP-Telefonie umgestellt werden musste, da ISDN generell abgeschaltet worden ist.

[Olli]

Moin in die Runde,

so langsam verzweifle ich mit Turbomed. Es ist tatsächlich die MTU 1400 gewesen, diese ich nun an den TI Arbeitsplätzen und Server einstellen musste, nun läuft die TI wieder.

Mein Netzwerker schüttelte nur mit dem Kopf, als er hörte, dass ich die MTU am Rechner und nicht am Router / Firewall ändern soll.
Aber tatsächlich schafft es Turbomed immer wieder mit neuen Fehlern zu überraschen.
Test Ping mit MTU Angaben brachten komplett andere Werte, aber hey... machen wir das was Turbomed sagt.

Also Lösung:
Server + Arbeitsplätze die TI Services nutzen MTU 1400 einstellen, in der Koco steht der Wert ebenfalls in der LAN Schnittstelle zum Intranet.

Danke für Eure / Ihre Hilfe.

[ebitdd]

Welchen Wert hast du in der Kocobox für LAN und VPN?

[Olli]

Welchen Wert hast du in der Kocobox für LAN und VPN?

Ich habe dort auch die 1400 hinterlegt.