Hallo

mir ist wohl jemand zuvorgekommen

http://sourceforge.net/project/showfiles.php?group_id=155271

Der Wrapper hat den Vorteil, das die Kommunikation zum CardReader über den PCSCD geht, da dieser standardmässig vom OSX bein einstecken eines cartenlesers gestartet wird. Somit muss dieser vor benutzung des Readers über den CTAPI Treiber nicht erst deaktiviert werden.

Bei den Eigenschaften für den Chipcarte (DDV) ist für den CTAPI Treiber die Datei .../pcsc-ctaip-wrapper-0.2/build/Release/libpcsc-ctapi-wraper-0.2.dylib auszuwählen.
Die funktion Tastatur des PCs zur PIN-Eingabe verwenden ist auszuwählen.

Momentan funktioniert Pinpad und Display noch nicht mit dem Treiber. Ich selber habe schon das PinPad schon mal zum laufen bekommen. Werde versuchen in den nächstn Tagen, das sauber in die Sourcen einzubauen. ggf finden sich ja auch noch ein paar leute zum Testen. Mir persönlich steht nur ein cyberJack von ReinerSCT zur verfügung.

Zum CyberJack selber hat auch seine macken. So funktioniert der CardReader nach dem der Rechner im Ruhestand war nicht mehr. Erst nachdem der CardReader abgesteckt und wieder angesteckt wird läst er sich wieder zum arbeiten überreden. Das gleiche, wenn der CardReader an einem USB - HUB mit steckernetzteil angeschlossen ist. Dort tritt das Problem auch beim Ausschalten des MACs auf. Vermitlich unsauberkeiten in der USB Implementierung, nur wer dafür verantwortlich ist OSX oder Reiner kann ich nicht sagen.

Gruss

Hey, das klingt gut. Werde Mac-User kuenftig darauf hinweisen, wenn sie nach Hibiscus+MacOS+Kartenleser fragen.

hallo Termite !

Der Wrapper ist toll, leider funktioniert bei mir nicht. muss man ein zusätzlich CTAPI installieren oder reicht der Wrapper schon aus?
(ich habe nur PCSC Treiber zum ReinerSCT Kartenleser installiert)

-------------------
[hbci4java]<DBG> [2009.03.25 16:31:53.895] [main/main] passport.AbstractHBCIPassport: creating new instance of a DDV passport
[hbci4java]<DBG> [2009.03.25 16:31:53.906] [main/main] passport.HBCIPassportDDV: trying to load native DDV library /libhbci4java-card-mac.jnilib
[hbci4java]<DBG> [2009.03.25 16:31:53.908] [main/main] passport.HBCIPassportDDV: using chipcard terminal with port 1 and terminal number 0
[hbci4java]<DBG> [2009.03.25 16:31:53.908] [main/main] callback.HBCICallbackThreaded: hbci thread: threaded callback received
[hbci4java]<DBG> [2009.03.25 16:31:53.909] [main/main] callback.HBCICallbackThreaded: hbci-thread: non-execute-callback, calling real callback
<INF> [2009.03.25 16:31:53.909] MyCallBack callback: Bitte legen Sie jetzt die HBCI-Chipkarte ein
[hbci4java]<DB2> [2009.03.25 16:31:53.913] [main/main] passport.HBCIPassportDDV: loading lib ok
[hbci4java]<DB2> [2009.03.25 16:31:53.914] [main/main] passport.HBCIPassportDDV: initializing CTAPI ok
[hbci4java]<DB2> [2009.03.25 16:31:53.917] [main/main] passport.HBCIPassportDDV: resetCT apdu: 20 11 00 00
[hbci4java]<DB2> [2009.03.25 16:31:53.917] [main/main] passport.HBCIPassportDDV: resetCT response: 90 00
[hbci4java]<DB2> [2009.03.25 16:31:53.918] [main/main] passport.HBCIPassportDDV: resetCT: success
[hbci4java]<DB2> [2009.03.25 16:31:53.918] [main/main] passport.HBCIPassportDDV: requestFunctionalUnits apdu: 20 13 00 81 00
[hbci4java]<DB2> [2009.03.25 16:31:53.919] [main/main] passport.HBCIPassportDDV: requestFunctionalUnits: -1 (invalid parameter or value)
[hbci4java]<DB2> [2009.03.25 16:31:53.919] [main/main] passport.HBCIPassportDDV: requestFunctionalUnits: -1 (invalid parameter or value)
[hbci4java]<DB2> [2009.03.25 16:31:53.920] [main/main] passport.HBCIPassportDDV: requestFunctionalUnits: -1 (invalid parameter or value)
[hbci4java]<DB2> [2009.03.25 16:31:53.920] [main/main] passport.HBCIPassportDDV: aborting
[hbci4java]<DB2> [2009.03.25 16:31:53.921] [main/main] passport.HBCIPassportDDV: requestCard apdu: 20 12 01 01 01 3C 00
[hbci4java]<DB2> [2009.03.25 16:31:54.419] [main/main] passport.HBCIPassportDDV: requestCard response: 62 00
[hbci4java]<DB2> [2009.03.25 16:31:54.420] [main/main] passport.HBCIPassportDDV: requestCard: timeout
[hbci4java]<DB2> [2009.03.25 16:31:54.420] [main/main] passport.HBCIPassportDDV: ATR: unknown coding convention!
[hbci4java]<DB2> [2009.03.25 16:31:54.421] [main/main] passport.HBCIPassportDDV: there are 0 historical bytes:
[hbci4java]<DB2> [2009.03.25 16:31:54.422] [main/main] passport.HBCIPassportDDV: ejectCard apdu: 20 15 01 04 01 01
[hbci4java]<DB2> [2009.03.25 16:31:54.581] [main/main] passport.HBCIPassportDDV: ejectCard response: 90 00
[hbci4java]<DB2> [2009.03.25 16:31:54.581] [main/main] passport.HBCIPassportDDV: ejectCard: success
[hbci4java]<DB2> [2009.03.25 16:31:54.582] [main/main] passport.HBCIPassportDDV: resetCT apdu: 20 11 00 00
[hbci4java]<DB2> [2009.03.25 16:31:54.582] [main/main] passport.HBCIPassportDDV: resetCT response: 90 00
[hbci4java]<DB2> [2009.03.25 16:31:54.583] [main/main] passport.HBCIPassportDDV: resetCT: success
[hbci4java]<DB2> [2009.03.25 16:31:54.583] [main/main] passport.HBCIPassportDDV: requestFunctionalUnits apdu: 20 13 00 81 00
[hbci4java]<DB2> [2009.03.25 16:31:54.584] [main/main] passport.HBCIPassportDDV: requestFunctionalUnits: -1 (invalid parameter or value)
[hbci4java]<DB2> [2009.03.25 16:31:54.585] [main/main] passport.HBCIPassportDDV: requestFunctionalUnits: -1 (invalid parameter or value)
[hbci4java]<DB2> [2009.03.25 16:31:54.585] [main/main] passport.HBCIPassportDDV: requestFunctionalUnits: -1 (invalid parameter or value)
[hbci4java]<DB2> [2009.03.25 16:31:54.586] [main/main] passport.HBCIPassportDDV: aborting
[hbci4java]<DB2> [2009.03.25 16:31:54.587] [main/main] passport.HBCIPassportDDV: closing CTAPI ok
[hbci4java]<DBG> [2009.03.25 16:31:54.587] [main/main] callback.HBCICallbackThreaded: hbci thread: threaded callback received
[hbci4java]<DBG> [2009.03.25 16:31:54.587] [main/main] callback.HBCICallbackThreaded: hbci-thread: non-execute-callback, calling real callback
[hbci4java]<ERR> [2009.03.25 16:31:54.589] [main/main] resources.HBCIMessages: HBCI4Java internal error: no translation for msgid DBG_CLB_ENDCHIPCARD provided
[hbci4java]<DBG> [2009.03.25 16:31:54.589] [main/main] DBG_CLB_ENDCHIPCARD
<---HBCI EXCEPTION BEGIN--->
org.kapott.hbci.exceptions.CTException: error while waiting for chipcard - ret=0 response=62 00 (timeout)
<---HBCI EXCEPTION END--->
ursache: error while waiting for chipcard - ret=0 response=62 00 (timeout)
----------------

hallo Termite,

ich habe noch etwas gefunden. Der Wrapper funktionirt unter Mac 10.4 nicht, läuft aber unter Mac 10.5. ich vermute du hast 10. 5.

Mac 10.5 enthält pcsc 1.40, unter Mac 10.4 gib es ein pcsc der Version 1.1.2, darin könnte das Problem liegen.

Es wäre schön , dass der Wrapper auch den alten Mac unterstützt.

Es gibt ein Update vom der Mac-Zweig auf Version 0.3. Kann sein, dass jetzt auch das PinPad vom Leser geht.

Das Projekt ist jetzt bei SourceForge hier:
http://sourceforge.net/projects/pcsc-ctapi/files/

Sorry at all das ich mich so lange hier nicht hab sehen lassen,

Ich hab das damals auf Mac 10.5.x gemacht und die lib damals selber übersetzt.

die PCSC versionen von Apple sind etwas frustrierend, sie haben teilweise eine eigene nummerierung, und entsprechen nicht den ständen des Linux Projektes. Es sind teilweise sachen weggelassen worden.

Meiness wissens funktioniert PIN PAD mitlerweile unter linux.
Einen vorabstand hab ich mal unter Mac 10.5 angetestet und probleme beim übersetzen. Die PCSD Implementierung bringt nicht die notwendigen defines mit. Daher kann die implementierung eigentlich nicht komplett funktionieren.

v0.3 hab ich kurtz angetestet. Reiner SCT + Mac 10.5.8 funktiniert nur ohne pin pad. mit pin pad bekomm ich fehlermeldungen.

Algemein kann ich nur sagen, MAC OS + PCSC + HBISCUS ist etwas schwierig zum einrichten ist, bzw einige macken hat an die man sich gewöhnen muss. wobei hier eher MAC OS + PCSC die probleme verursachen.

1. Kartenleser nach gebrauch vom USB Bus trennen. Der kartenleser wird nach dem aufwachen aus dem Standby nicht sauber erkannt. das gleiche, wenn der Kartenleser an einem self powerd USB hub angeschlossen ist, und der HUB samt angeschlossenem Kartenleser angeschlossen wird.

2. sollten beim einrichten des kartenlesers in Hibuscus probleme auftauchen, sollte der kartenleser vom MAC getrennt werden, und hibiscus neu gestartet werden. und erst danach die neuen einstellungen bzw. die neue lib probiert werden.
ggf ist bei dem vorgang auch der pcscd dienst manuell zu killen. der pcscd wird automatisch wieder gestartet, wenn der chipkartenleser neu angeschlossen wird.
irgend jemand scheint hier noch mit alten handels oder verweisen zu arbeiten, wer weiss ich nicht.

3. das automatische starten des PCSCD dienstens unter MAC ist auch das problem wieso die CTAPI treiber nicht funktionieren bzw nur mit "masieven" eingriffen im system zum laufen zu bewegen sind. pcscd krallt sich den leser, womit CTAPI keine verbindung mehr aufbauen kann. (ausweg die erkennung und das starten vom PCSCD unterbinnen)

4. die linux implementerung des PCSC - CTAPI Wrapers konnte man auch dadurch zu vollem funktionsumfang bewegen, in dem man die PCSCD implementierung durch eine eigenübersetzung austauscht. sicher auch nicht die schönste lösung.

ich versuch noch mal mit dem Maintainer kontackt aufzunehmen wie er das jetzt haben will.

bitte auch testberichte hier posten, was getan hat, was nicht. Es scheint ja mehr leute zu geben, die sich dafür interresieren. ggf sind die ja auch bereit als versuchskaninchen her zu halten

gruss michael

Soweit ich weiss, soll die Sicherheitsarchitektur von Mac OS X einen Zugriff auf Sicherheitskomponeneten oder -hardware (wie auch Kartenleser) verhindern; also auch dass sich etwas anderes als der pcscd damit verbindet oder "dazwischen hängt", damit diese nicht kompromittiert werden.

Aber da es sich hierbei um einen Wrapper handelt, der ctapi-Calls auf die PC/SC-API wrappt, sollte man auch nicht versuchen den pcscd lahm zu legen, weil sonst der Wrapper nicht mehr funktioniert.

Der PCSCd ist eigentlich nur ein Dienst, der Aufgrund der HW erkennung automatisch gestartet wird, wenn ein Chipkartenleser am USB Bus angesteckt wird. Wenn man nun den PCSCp Dienst über die konsole Killt, dann kann man den CTAPI Treiber verwenden und direckt auf die HW zugreifen.

Um das starten des PCSCd zu verhindern gibt es eigentlich nur 2 möglichkeiten
1. die HW erkennung davon zu überzeugen, das für dieses entsprechende Device kein PCSCd zu starten ist.
2. die HW erkennung komplett lahm zu legen.

beides nicht gerade die feine englische art.

Der Wrapper gaukelt der Anwendung nur einen CTApit Treiber vor, und setzt die anfragen auf PCSCd anfragen um.

nur wieso die Homebanking anwendungen immer noch auf den alten CTAPI ... aufsetzen verstehe ich nicht. PCSCd gibts auch schon unter Windows, unterstützt multi user Handling ( mehrere anwendungen können auf einen kartenleser zugreifen ) ...

Du scheinst auf einem anderen System zu Hause zu sein. Das Fazit ist im Grunde aber okay. Prinzipiell sollte man nicht an essentiellen Systemdiensten herumfingern, und arglose User auch nicht dazu verleiten. In diesem Fall ist es ganz besonders nicht zu empfehlen.

Wenn Dich das Thema interessiert, rate ich Dir Dich bei der apple-cdsa list anzumelden.


Das sind zu meist einfach Altlasten. Und ohne Not werden die nicht ersetzt.

Was sich auch mir nicht recht erklärt, weshalb selbst bei Neuentwicklungen teilweise verbissen versucht wird wieder die alte ct-api zu reanimieren, anstatt einfach PC/SC zu verwenden. Ich denke das muss eine Art Betriebsblindheit sein, weil logisch und vorausschauend ist es nicht.

Das ist zumindest im Fall von HBCI4Java / Hibiscus so der Fall. Der erste Chipkarten-Code (mit CTAPI) entstand ca. 2001. Seitdem wurde das nicht geändert - zu viel Aufwand, zu wenig Nutzen im Vergleich dazu und zu wenig Zeit, das mal ebenso zu machen...

Grüße
-stefan-