Hallo,
wie es scheint sind ich und Listor (siehe Beitrag http://www.onlinebanking-forum…highlight=)
die einzigen mit der Fehlermeldung:

gnucash$ aqhbci-tool getsysid
....
....
===== Password eingeben =====
Bitte geben Sie das Passwort für
XXXXXXXX
ein
Input: *****
4:2007/05/30 20-21-47:gwen(6384):msgengine.c: 2848: Found a bad character (0c) in type "AN", converting to SPACE
4:2007/05/30 20-21-47:gwen(6384):msgengine.c: 2848: Found a bad character (93) in type "AN", converting to SPACE
...
...
3:2007/05/30 20-21-47:gwen(6384):nl_ssl.c: 404: Socket is inactive: disconnected (4)
3:2007/05/30 20-21-47:aqhbci(6384):dialog.c: 628: Could not disconnect from bank (-6)
3:2007/05/30 20-21-47:aqhbci(6384):outbox.c: 1330: Error performing queue (-1)
3:2007/05/30 20-21-47:aqhbci(6384):provider.c: 1085: No system id
3:2007/05/30 20-21-47:(null)(6384):getsysid.c: 140: Error getting system id (-11)

Im o.g. Beitrag scheint es, als ob der Fehler gelöst worde wäre. Leider steht die Lösung nicht mit dabei.

Deshalb reiche ich die Frage an euch weiter, ob jemand dieselbe Fehlermeldung bekommt und eine Lösung dafür hat ?

Danke
(Debian 4.0 Etch, Gnucash und Aqbanking-2.2.3 mit HBCI Untersützung selbst gebaut, Bank: KSK-Heidenheim via HBCI PIN/TAN)

Ohne detailiertere Logs kann ich dazu wenig sagen... Du koenntest ja mal vorher die Umgebungsvariable AQHBCI_LOGLEVEL auf "info" oder auf "debug" setzen. Wenn Du damit Logs erstellst, solltst Du diese mit meinem Schluessel verschluesseln (zu finden auf der Homepage von AqBanking/Libchipcard, unten links).


Gruss
Martin

So,
nun habe ich 2 Logfiles beigelegt:
1) Das Logfile aus dem ./banking/backends/..../logs/ Verzeichnis
2) Die Konsolenausgabe mit AQHBCI_LOGLEVEL=debug

In 1) sind am Ende die fehlerhaften ("found a bad character") Zeichen zu finden, die meiner Meinung nach den Fehler verursachen!

Hmm, die Antwort der Bank enthaelt nur Muell?? Funktioniert eventuell momentan der Server der Bank nicht? Als Antwort auf die HBCI-Nachricht kommt jedenfalls nur irgendein Wirrwarr zurueck. Das kann an 3 Dingen liegen:
1) Der Bank-Server sendet unbrauchbare Daten
2) irgendwo gibt es ein Problem in der Decodierung der Daten in OpenSSL
3) die Antwort der Bank ist nicht BASE64 kodiert, aber trotzdem geht sie glatt durch den entsprechenden Parser

Die beiden letzten Moeglichkeiten sind ziemlich unwahrscheinlich, man muesste in diesem Fall wohl ein intensives Logging einbauen (z.B. zwischen AqHBCI und dem OpenSSL-Layer), um die genaue Ursache zu finden...

So kann ich da momentan nicht viel mehr zu sagen...

Ist das Problem neu (hat es schon mal geklappt) oder hast Du es jetzt zum ersten Mal probiert und es funktionierte gleich nicht?


Gruss
Martin

Hallo,
ich habe die letzten Jahr nur Online-Banking via Browser gemacht.
Ich habe noch nie! via aqbanking/hbci onlinebanking betrieben.
Da ich seit Anfang des Jahres von SuSE auf Debian umgestiegen bin, und nun gerne GNUcash verwenden möchte, war es notwendig, das HBCI-Modul selbständig in aqbanking einzubauen. (Debian ETCH 4.0 upgrade von Debian Sarge)
Ich habe also nach Anleitung die Quellen geholt, die Rules geändert, das Paket gebaut, und installiert (sowohl für GNUcash als auch für AQbanking).
1)Könnte ich dabei einen Fehler gemacht haben ?

GNUcash funktioniert anscheinend, und wenn ich die aqbanking-logs richtig verstehe, klappt die Kommunikation mit dem Bankserver auch, solange nicht versucht wird eine Sichere Verbindung aufzubauen.
2) Stimmt das, oder sendet die Bank schon bei der ersten Antwort Müll?

Desweiteren wundert mich, dass Ligor (im o.g. Beitrag von 2006) erwähnte, auf seinem Heim-Server hätte es funktioniert, nur auf seinem anderen Server nicht. Das sieht so aus als liegt das Problem in einer Konfiguration/Decodierung/ etc. wie Du erwähnt hast.
Daher würde ich gern diese Einstellungen ändern und testen ob sich was ändert.

3) Gibt es Prozesse die diese Kommunikation beeinträchtigen können (firewall, tor, privoxy) bzw. unbedingt vorhanden sein sollen (z.B. SSL/SSH, gpg....)?

4) Kann man aqbanking/openssl beibringen anstatt BASE64 andere Kodierungen (z.B. Radix64, Base85...) oder Zeichnsätze zu verwenden?

Gruß
Holger

Ich möchte mal einen Test bei einer Bank machen, bei der das HBCI-Interface definitiv funktioniert. Auch wenn ich dort kein Konto habe, sollte doch die Antwort der Bank durch meine SSL dekodiert werden können und eine klare Fehlermeldung enthalten. So könnte ich den Fehler (ob Bank-Server oder SSL) eingrenzen.
Könnt Ihr mir eine funtionierende Adresse nennen?

Danke
Holger

Nachtrag:
Könnte es an einer GNUTls / OpenSSl inkompatibilität in Debian Etch liegen?

Holger

Nun bin ich selbst darauf gekommen:

Nachdem ich von aquamaniac darauf hingewiesen wurde, dass der Bank-Server meiner Bank nur Müll sendet, und ich mir relativ sicher war, dass ich bei der Einrichtung von aqbanking keinen grober Fehler gemacht habe, blieb mir nur andere Banken zu testen, bei denen ich zwar kein Konto habe, aber eine irgenwie andersgeartete Fehlermeldung bzw. Serverantwort erwate.
Nach dem dies erfolgreich war und der Server der anderen Bank nicht so einen Müll sendete, bin ich bei einer anderen Kreissparkasse darauf gestossen, dass diese (andere) Bank einen Server anbietet, welcher nicht mit dem Banknamen verknüpft ist, sondern generell für KSK's zu gelten scheint. Daher habe ich kurzerhand diesen Server mit meinen Kontendaten getestet: UND ES HAT FUNKTIONIERT !!!

Problem: Meine Bank kennt Ihre eigene Serveradresse nicht !!!!
Das ärgerliche ist, dass ich mit meiner Bank telefoniert habe, und diese mir 2x bestätigt hat, dass die Webbrowser-Internetbanking-Adresse auch für HBCI-PINTAN gültig ist und es damit funktionieren müsste, was definitiv nicht der Fall ist. Diese FALSCHE Adresse hat diesen Müll als Antwort gesendet und den Fehler verursacht. Ich werde die Bank darauf hinweisen.

Erkenntnisse:
1) Bei (einigen) Kreissparkassen in BaWü wird folgende Adresse verwendet: https://hbci-pintan-bw.s-hbci.de/PinTanServlet !
2) Es kommt vor, dass auch die Bank (bzw. deren Beauftragter) nicht weiss welchen Server man verwenden muss um HBCI PINTAN zu verwenden !

Vorschlag (falls es dies nicht schon gibt):
In diesem Fall wäre es sehr von Vorteil gewesen, es gäbe einen Test-Server mit Test-Zugang oder so, um zumindest die HBCI Schnittstelle testen zu können.

Holger

Abgesehen davon, dass man sich mit HBCI4JAva selber einen Test-Server aufsetzen kann, haette Dich das ja auch nicht weitergebracht: Dass die Schnittstellen von AqHBCI funktionieren, wissen wir ja schon. Der Test mit einem Test-Server haette also nicht zum Ziel gefuehrt.

Kompliment uebrigends, auf die Idee, einen quasi fremden Server mit den eigenen Zugangsdaten zu testen, muss man erst mal kommen


Gruss
Martin

Hallo Holger,

nicht nur Kreis- sondern schlicht alle Sparkassen in Baden-Würtemberg werden diese Server-Adresse nutzen. Die Sparkassen in D betreiben natürlich einen zentrale IT in einem gemeinsamen Rechenzentrum. Einzige Ausnahme dürften noch sogenannte Eigenanwender sein, dafür gibt es aber nicht mal mehr 5 Stück, in Bawü wohl gar keine mehr. Das "bw" in der Serveradresse ist übrigens das Kennzeichen für das Bundesland.

Die genauen Zugansgdaten und einige Besonderheiten haben wir im Laufe der Zeit mal zusammengestellt. Schau mal hier: http://www.onlinebanking-forum…php?t=1174

Zu der Auskunft der Bank kann ich wenig sagen, ich denke schon das man als eBanker die 4 Serveradressen die es abseits des Webauftritts gibt, definitiv kennen sollte. Ich weiss aber auch nicht mit wem du gesprochen hast.

Im Prinzip koennte man AqHBCI ja alles moegliche beibringen, aber festgelegt ist halt BASE64, etwas anderes versteht daher der Kommunikationspartner nicht. Wuerde also auch nicht weiterbringen.


Gruss
Martin

Hallo,
nachdem ich jetzt mehrere Tage erfolgreich mit GnuCash und Aqbanking gearbeitet habe und alles wie am Schnürchen läuft, möchte ich mich beim Forum für die schnelle Unterstützung und Hilfe bedanken.
Ohne eure Tipps hätt ich noch lange nach dem Fehler gesucht !

Alles Gute