[pcscd stürzt ab beim Entfernen des Lesers]

11. April: Keine Antwort von niemandem. Sehr unbefriedigende Situation. Xubuntu 14.04 meldet nach jedem Login einen abgestürzten pcscd.

 

Der Reader funktioniert zwar nach einem Neustart des pcscd, aber das ist doch alles sehr lästig. Schade, dass das niemanden interessiert.

[pcscd stürzt ab beim Entfernen des Lesers]

Unglaublich, dass nach über einem Jahr (oder länger) das Problem immer noch besteht!

 

 

 

Wir schreiben das Jahr 2017, ich nutze Xubuntu 14.04.5 LTS und seit gestern den Cyberjack RFID Standard, habe ihn mit Moneyplex zum Laufen gebracht, habe anschließend die Abstürze bemerkt und bin nun hier gelandet.

Situation: Cyberjack ist nicht angeschlossen, pcss-Daemon läuft nicht

root@ltp:/tmp# /usr/sbin/pcscd --foreground --debug
00000000 debuglog.c:269:DebugLogSetLevel() debug level=debug
00000216 configfile.l:254:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d
00000033 configfile.l:266:DBGetReaderListDir() Skipping non regular file: .
00000009 configfile.l:266:DBGetReaderListDir() Skipping non regular file: ..
00000014 configfile.l:307:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/libccidtwin
00000073 pcscdaemon.c:545:main() pcsc-lite 1.8.10 daemon ready.
00001825 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001
00000137 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001
00000138 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x8087, PID: 0x0020, path: /dev/bus/usb/001/002
00000144 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0A5C, PID: 0x217F, path: /dev/bus/usb/001/003
00000138 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0A5C, PID: 0x217F, path: /dev/bus/usb/001/003
00000134 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0A5C, PID: 0x217F, path: /dev/bus/usb/001/003
00000129 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0A5C, PID: 0x217F, path: /dev/bus/usb/001/003
00000129 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x8087, PID: 0x0020, path: /dev/bus/usb/001/002
00000163 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001
00000121 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001
00000129 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x8087, PID: 0x0020, path: /dev/bus/usb/002/002

(Cyberjack wird angeschlossen)

12422064 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0C4B, PID: 0x0500, path: /dev/bus/usb/002/005
00000025 hotplug_libudev.c:321:HPAddDevice() Adding USB device: REINER SCT cyberJack RFID standard
00000077 readerfactory.c:989:RFInitializeReader() Attempting startup of REINER SCT cyberJack RFID standard (1044480224) 00 00 using /usr/lib/pcsc/drivers/libifd-cyberjack.bundle/Contents/Linux/libifd-cyberjack.so
CYBERJACK: Started
00001675 readerfactory.c:874:RFBindFunctions() Loading IFD Handler 3.0
02173357 readerfactory.c:327:RFAddReader() Using the pcscd polling thread

(Cyberjack wird abgezogen: CRASH)

RSCT: No USB context.}nSpeicherzugriffsfehler (Speicherabzug geschrieben)
root@ltp:/tmp# 

Was tun?

[Minütliche Updateversuche, obwohl Proxy meckert]

Ich stelle zum jetzigen Moment fest: Man möchte nur telefonieren und hat kein Interesse daran, hier im Forum auf meine Fragen eine Antwort zu liefern, die ggf. auch anderen Benutzern oder Forenbesuchern eine Hilfestellung sein könnten.

[Minütliche Updateversuche, obwohl Proxy meckert]

ich habe die PN beantwortet, bitte antworten.

[Minütliche Updateversuche, obwohl Proxy meckert]

Die Windows-Treiber scheinen regelmäßig die reiner-sct.de-Server anzurufen und nach Updates zu schauen. Dabei wir ein base64-encodetes XML-File per HTTP GET übertragen. Das sieht dann im Proxy-Log etwa so aus wie im ersten Anhang. Das XML-File selbst sieht etwa so aus wie im zweiten Anhang (btw: was wird da eigentlich alles übertragen?)

 

Problem: Durch die langen XML-Tagnamen ergibt sich ein langes base64-Encoding und entsprechend eine ziemlich lange URL für den HTTP-GET-Request. Unser alter Proxy reicht diesen Request nicht durch und liefert einen TCP_DENIED/400 zurück und syslogt "URL too large".

 

Problem Nummer 2: Die Update-Routine weiß offenbar nicht damit umzugehen und versucht es eine Minute später ein weiteres Mal.

 

Problem Nummer 3: Und so haben wir am Ende des Tages 8 Stunden mal 60 Minuten sprich das ganze Proxy- und Syslog voller immergleicher Einträge.

 

Doof

 

BTW: Es treibt mir ein paar Runzeln auf die Stirn, wenn ich feststelle, dass ein aus Sicherheitsgründen erworbenes Gerät regelmäßig mehrere Kilobyte große XML-Dateien nach Hause schickt, nur um zu schauen, ob es ein Update gibt. Wo kann man das abstellen?