E-RP, E-AU, KIM nicht ereichbar trotz Verbindung - Datenbankproblem? [GELÖST]

[Molustan]

Hallo Zusammen,

seit gestern morgen funktionieren KIM, eAU, eRP nicht mehr. Konnektor-Neustart und Serverneustart ohne Effekt, KIM verbunden, Konnektor verbunden, Kartenlesegerät intakt. Keine sichtbaren Dysfunktionen.

Resultat der Fernwartung gestern: es gäbe ein Problem mit der Datenbankkompression, wäre behoben, alles wieder ok. In Folge alle Signaturen möglich.

Seit heute morgen kurz nach acht dasselbe Fehlerbild. Resultat der Fernwartung: es müsse jetzt wieder gehen. Ging auch für 5 Minuten, danach wieder dieselben Fehler:
e-AU: Empfangsadresse kann nicht ermittelt werden
e-Rp: Signatur mit Praxisausweis wird versucht, scheitert an Java-Problemen (Fehlermeldung abgeschnitten, kann nicht eingesehen werden)
KIM: Source:mscorlib, Line: 1084 Char: 3 Error0 Vorgang nicht verfügbar

Fazit Hotline: es muss eine Datenbankwartung her, Dauer 1-2 Werktage. Kennt jemand das Fehlerbild? Eine Reorganisation ist für uns zeitlich aktuell unmöglich. Für Ideen wären wir sehr dankbar.

Viele Grüße,
Molustan

[lcer]

Hallo,

kann man in den Fehlerprotokollen im Konnektor das nachvollziehen? Also: Werden dort Fehler protokolliert, wenn man versucht eAU/KIM zu verwenden? Oder kommt da gar nichts an?

Weitere Fehlermeldungen kann man nachverfolgen unter Patientenmenü/Kommunikation/CGM Connect/CGM Connect Verbindungsdiagnose/Log.

Grüße

lcer

[Molustan]

Vielen Dank für die schnelle Rückmeldung.

Bei den heutigen Verwendungen wurden keine Fehler protokolliert. Gestern Nachmittag wurde vermerkt:
- Protokollspeicher zu mehr als 80% gefüllt
- Das für die Authentifizierung gegenüber dem Clientsystem konfigurierte Zertifikat hat ein Sicherheitsniveau von weniger als 120bit

Die Verbindungsdiagnose zeigt:
- keine Verbindung zum Port für eGesundheitskonnektor
- keine Verbindung zum cgmConfigService
- keine Verbindung zum telemed-Verzeichnis
- EPrescription: Konstante und aktive Routen sind nicht richtig eingestellt
- eth3 hat MTU von 1500

VG

[lcer]

Hallo,

ich meinte die Protokolle unter KoCoBox-Managementschnittstelle / Menü / Protokollierungsdienst / Systemprotokoll

und unter Turbomed CGM Connect Verbindungsdiagnose: Karteireiter "Log"

Grüße

lcer

[PC Fuzzy]

Welchen Internetprovider haben Sie. Falls es Vodafone sein sollte müssten die MTU Werte geändert werden. Bei uns ging auch von einen Tag auf den anderen Tag keine eAU, eRezepte. Kim Mails konnten wir auch nicht abrufen. Seit die MTU Werte geändert wurden funktioniert alles wie gehabt.
MfG PC Fuzzy

[Molustan]

Guten Morgen,

wir haben htp. Inhaltlich passt das genau zu unserem Fehlerbild. Vielen Dank für den Tip, das gebe ich an Turbomed weiter.

@Icer
Systemprotokoll:
log=11%; VmSize_ak=8738504kB; fd_ak=321; update=13%; uptime=144984s; fd_sys=992; VmSize_nk=5155636kB; fd_nk=100; oom_kill=0; sec2=8%; sec1=8%; MemAvailable=58%; root=41%; loadavg=1.00 1.00 1.00
Verbindungsdiagnose:
EBUG] xmpp.core.session.XmppClient - Resource binding completed, connected resource: 73eo166o6g@connect.cgm.com/73eo166o6g.
[DEBUG] xmpp.core.session.XmppClient - Stream negotiation completed successfully.
[DEBUG] xmpp.core.session.XmppClient - Login successful.
[INFO ] plugins.connectdiagnostic.internettest.FirewallTestService - enabled.firewall
[WARN ] plugins.connectdiagnostic.internettest.ThirdPartyFirewallTestService - Parsing of firewall information failed.
[INFO ] plugins.connectdiagnostic.internettest.ThirdPartyFirewallTestService - Third party firewall unknown.
[INFO ] plugins.connectdiagnostic.internettest.GatewayTestService - Gateway present

Das sind die letzten Einträge.

[lcer]

Hallo,

Wenn es die MTU ist, sollten Fehler im Systemprotokoll des Konnektors auftauchen. Die MTU ist relevant vor Verbindungen über den VPV Tunnel zwischen Konnektor und der Telematikimfrastruktur.

Für die Verbindung zwischen Turbomed und Konnektor spielt sie keine Rolle.


Im CGM Connect Log musst Du auf Einträge mit ERROR achten.

Behebt die kleinere MTU das Problem eigentlich?

Grüße

lcer

[PC Fuzzy]

Hier ein Link zu den Threads die das MTU Thema behandelt.
viewtopic.php?p=69608&sid=33998c466a95a ... 94d#p69608

MfG PC Fuzzy

[lcer]

Zum Thema MTU - im verlinkten Tread werden kopfschüttelnde Netzwerktechniker erwähnt ... Daher:

Zuerst würde ich die MTU am Konnektor ändern:
KoCoBox-Managementschnittstelle / [WAN / LAN] / [LAN] / [Länge IP-Pakete (MTU):] auf z.b. 1400 stellen
KoCoBox-Managementschnittstelle / [WAN / LAN] / [WAN] / [Länge IP-Pakete (MTU):] auf z.b. 1400 stellen

Das müßte eigentlich (bei normgerechten TCP/IP Netzwerken) genügen.

Nur wenn das nicht zum Erfolg führt, sollte man versuchen, die MTU am Client zu ändern. Sollte das dann nichts nützen, die MTU am Client wieder auf den Standartwert stellen. Das Problem liegt dann anderswo und "verbastelte" Netzwerkeinstellungen könne später unerwartet Probleme machen.

Warum muss man manchmal die MTU ändern? Netzwerke benutzen zusätzliche Netzwerkprotokolle, um Verbindungen zu ordnen oder abzusichern. Beispiele sind VLANs und VPN-Verbindungen. Diese zusätzlichen Verbindungsprotokolle fügen Daten an das zu transportierende Datenpaket an. wird das deshalb zu groß, passt das Datenpaket nicht mehr "durch die Tür" eines Routers (z.B. Konnektor, Router im Innereren der Telematikinfrastruktur, etc.). Um es dennoch zuzustellen, muss das Datenpaket beanstandet, zerlegt und erneut zugestellt werden. Das kostet Zeit stellt eine Fehlerquelle dar. Eine kleinere MTU sorgt dafür, dass von Anfang an nur noch kleine Pakete gepackt werden. Allerdings sind es das auch mehr Pakete und die Zustellung verlangsamt sich. Daher gilt: MTU so klein wie nötig und so groß wie möglich.

Beispiel sind:
- viele Internetanschlüsse nutzen VPNs zur Unterteilung zwischen Internetdaten und Telefoniedaten.
- der Konnektor stellt eine VPN Verbindung zur Telematikinfrasturktur her
- Die Verbindung zwischen zwei Praxisstandorten läuft über ein VPN

In diesen Fällen hilt eine kleinere MTU.

Grüße

lcer

[Molustan]

Werde ich heute Mittag gleich versuchen. Tausend Dank.

Wir haben nochmal auf allen Rechnern die Verbindungsdiagnostik gecheckt: auf den Rechnern, die einen MTU-Error zeigen (1500 statt 1400), funktioniert e-rp, kim, e-au nicht. Auf den Rechner ohne Errror bei der MTU funktioniert alles. Das spricht ja für die Vermutung.

Ich frage mich allerdings, warum die Hotline nicht auf die Idee kommt (wo doch anscheinend schon andere Praxen das Problem hatten) und warum bei keiner der vielen Ansprechpartner in den Fernwartungen in die Verbindungsdiagnostik geschaut hat?

Ich werde berichten.

[Molustan]

Die Clients haben also anscheinend alle unterschiedliche MTU-Einstellungen. Kann es zum Problem führen, wenn ich dann am Konnektor runterregele?

[lcer]

Hallo,

vielleicht auch mal in der Firewalleinstellungen von Windows schauen, ob ICMP eingehend erlaubt ist. Insbesondere ICMP-Typ 3, Code 4 („Fragmentation Needed“) also unter Windows: "Kernnetzwerk - Ziel nicht erreichbar, Fragmentierung erforderlich" oder ICMPv4/Alle Type zulassen. Sonst kann Windows nicht wissen, wenn es am Konnektor einen MTU-Engpass gibt und die Paketgröße anpassen.

Grüße

lcer

[FortiSecond]

Hallo,

vielleicht auch mal in der Firewalleinstellungen von Windows schauen, ob ICMP eingehend erlaubt ist. Insbesondere ICMP-Typ 3, Code 4 („Fragmentation Needed“) also unter Windows: "Kernnetzwerk - Ziel nicht erreichbar, Fragmentierung erforderlich" oder ICMPv4/Alle Type zulassen. Sonst kann Windows nicht wissen, wenn es am Konnektor einen MTU-Engpass gibt und die Paketgröße anpassen.

Grüße

lcer

Und wieder ein Goldnugget hier im Forum. Betrifft ja auch andere Desktop-Firewalls, z.B. ESET. Hat hier gerade ein "unerklärliches Langzeitproblem" in einem ganz anderen Zusammenhang gelöst. Da hätte ich im Leben nicht nach gesucht... D-A-N-K-E-!

[Molustan]

Guten Morgen,

im dritten Kontakt mit Turbomed (mit dem 7. Ansprechpartner in der Angelegenheit) stellt sich heraus, dass die MTU am Konnektor schon angepasst wurde, ebenso an den zwei Rechnern, an denen die zwei Fernwartungen liefen (auf denen auch die Signatur funktioniert). Heute Mittag haben wir die dritte Fernwartung, um die restlichen Arbeitsplätze anzupassen.

Vielen Dank an das tolle Forum und die Unterstützung. Ohne die Hintergrundinformationen hätte ich es nicht in die richtige Richtung steuern können.

VG

[Molustan]

Guten Morgen,

ich berichte kurz, was bei der Fernwartung raugekommen ist: Problem konnte nicht gelöst wurden, über 2h Fernwartung mit mehreren Ansprechpartnern. An der MTU läge es nicht, es würde jetzt eine Analyse gemacht und ein Satellit neu aufgesetzt um zu schauen, wo das Problem liegt.

Bei der Fernwartung zur Neuinstallation hat der Mitarbeiter innerhalb weniger Minuten die MTU angepasst und siehe da: alles klappte wieder an allen Satelliten. Pro Rechner 2min Arbeit, erfolgt waren schon drei ergebnislose Fernwartungen à 2 Stunden und der Hinweis, ohne Datenbankreparatur wird das nicht mehr funktionieren.

Ohne Worte. Es ist mir unbegreiflich, warum so ein Problem nicht gelöst werden kann, obwohl ich dank des Forums auf die MTU hinweise und es mit der Verbindungsdiagnostik belege.

Danke nochmals an alle für den Hinweis!
Molustan

[lcer]

Hallo,

meinst Du mit "Satellit" einen normalen PC im lokalen Netzwerk?

Grüße

lcer

[Molustan]

Hallo Icer,

ja, genau.

MfG