Problem EBICS mit Raifeisenlandesbank Oberösterreich

Dann müsste den Geno-Kollegen aus dem Süden (Fiducia) das Problem sehr bekannt sein. Dort ist ein Omikron Bankrechner zusammen mit dem PPI Client Kernel in Proficash im Verbund im Einsatz.
Oder alle SFirm oder ProfiCash Versionen, in denen eine Fiducia, ex Dresdner oder DeuBa EBICS-Bank eingerichtet ist.

Nur: Wenn zum Zeitpunkt des Problems auch kein Kontakt über den Browser möglich ist, kann der Fehler nur auf Bankseite oder in der Inetrnet-Verbidung des Kunden begründet sein. Da brauche ich mit über Sfirm32 oder jeden anderen Client keine weiteren Gedanken machen.

IMO hat die Dresdner ebenso (wie Holger bereits schrieb) die Fiducia mittlerweile den CoCoNet-Bankrechner; die Deutsche Bank setzt für EBICS eine speziell angepasste Version des PPI-Systems ein.

Den Omikron-Bankrechner setzen nach meinem Kenntnisstand im EBICS-Bereich mittlerweile nur noch ein paar Landesbanken und vielleicht ein paar kleinere KI's ein (die LBBW z.B.); ich habe es in meiner Praxis bisher immer nur mit PPI und CoCoNet-Systemen zu tun gehabt...

Otto

Sehr geehrter Herr XXXX,

zunächst einmal möchte ich festhalten, dass selbstverständlich auch unser Bankrechner EBICS-konform arbeitet (und u.a. für alle deutschen Privatbanken von der BV-Zahlungssysteme GmbH abgenommen ist). Wie in der Antwort der Sparkasse richtig dargestellt wird, treten diese Probleme ausschließlich mit Kundensystemen auf, die einen EBICS-Kernel der Firma PPI verwenden. Dieses Problem hat sich mit der Einführung einer neuen Client-Version offenbar extrem verstärkt.

Wir haben das Problem deshalb analysiert und folgende Hypothese zur Ursache gebildet.

1. Der PPI-EBICS-Kernel baut (neuerdings?) mehrere TLS-Verbindungen für eine Kommunikation auf. Das rührt möglicherweise daher, dass auf http 1.1 umgestellt wurde, wo 5 gleichzeitige Verbindungen zulässig sind (wenn auch im EBICS-Kontext nicht sinnvoll).

2. Es wurden zunächst von PPI mit einem Testprogramm und danach von uns mit einem anderen Testtool Lasttests für den TLS-Verbindungsaufbau durchgeführt (100 – 500 parallele Verbindungen). Dabei konnte die unten beschriebene Situation bei Kommunikation über das Internet (nicht jedoch über interne Netzwerkstrecken) produziert werden, die bzgl. der Symptome zu den Beobachtungen passt:

3. In unserem Gateway wurde bzgl. der IP-Socket-Verarbeitung eine ältere Windows-Voreinstellung benutzt, bei der die interne Liste der im Socket-Buffer zur Verarbeitung anstehenden, aber von der Applikationsschicht noch nicht entgegen genommen Verbindungen auf 5 begrenzt war. Wenn nun schneller Verbindungen aufgebaut werden, als von der internen Applikation innerhalb einer recht kurzen Zeitspanne (10 Sekunden) zur Verarbeitung angenommen werden, löst die Windows-Netzwerkschicht ein Reset-Kommando für die noch nicht endgültig angenommenen Verbindungen aus. Dies führt offenbar dazu, dass der PPI-Kernel oder SFIRM alle aufgebauten Verbindungen beendet und mit der Meldung „peer not authenticated“ abbricht.


4. Es gibt aber mehrere Beobachtungen von Seiten der BIVG (Hersteller SFIRM), die nicht so recht zu dieser Hypothese passen:

a) Dass ein Reset durch die oben beschriebene Situation ausgelöst wird, können wir bei einer Vielzahl von parallelen Verbindungsaufbauten erklären. Es wurden aber wohl solche Abbrüche auch beobachtet, wenn nur ein Clientsystem eine Verbindung aufgebaut hat und keine Last auf dem System war.

b) BIVG hat auch ähnliche Tests gegen andere unserer Banksysteme (mit gleicher Konfiguration) durchgeführt, bei denen dieses Problem nicht beobachtete wurden.

Ich möchte betonen: Dies ist unser Analyseergebnis und wurde bisher von PPI nicht kommentiert. Wir haben trotzdem ein entsprechendes Service-Pack für den Bankrechner und ein neues Release des Gateways mit den oben beschriebenen Änderungen erstellt. Ich schlage vor, dass Sie dieses in Abstimmung mit meinen Kollegen vom Service-Team installieren. Es wäre schön, wenn Sie uns auch im positiven Fall über das Ergebnis informieren könnten.

Mit freundlichen Grüßen / Best Regards,
Helmut Knester

-------------------------------------------------------------
Omikron Systemhaus
Von-Huenefeld-Strasse 55
D-50829 Koeln


=> Abwarten und auf Update der Hersteller Omikron/PPI warten