Alexander Leidinger

Just another weblog


Sta­tus crypto cards HOWTO: prob­lems with the card reader (sup­port could be better)

After hours (spread over weeks) I come to the con­clu­sion that there is a lot of poten­tial to improve the doc­u­men­ta­tion of card read­ers (but I doubt the card reader ven­dors will do it) and of the pcsc doc­u­men­ta­tion. It is not easy to arrive at a point where you under­stand every­thing. The com­pat­i­bil­ity list does not help much, as the card read­ers are partly past their end of life and the mod­els which replace them are not listed. Respec­tively the one I bought does not sup­port all the fea­tures I need. I even ported the dri­ver to FreeBSD (not com­mit­ted, I wanted to test every­thing first) and a lot of stuff works, but one crit­i­cal part is that I can not store a cer­tifi­cate on the crypto card as the card reader or the dri­ver  does not sup­port extended APDUs (needed to trans­fer more than 255 bytes to the card reader).

Well, the sta­tus so far:

  • I have a HOWTO what to install to use crypto cards in FreeBSD
  • I have a HOWOT what to install / con­fig­ure in Windows
  • I have a HOWTO regard­ing cre­at­ing keys on a openpgp v2 card and how to use this key with ssh on FreeBSD (or any other unix-like OS which can run pcsc)
  • I have a card reader which does not sup­port extended APDUs
  • I want to make sure what I write in the HOW­TOs is also suit­able for the use with Win­dows / PuTTY
  • it seems Win­dows needs a cer­tifi­cate and not only a key when using the Win­dows CAPI (using the ven­dor sup­plied card reader dri­ver) in PuTTY-CSC (works at work with a USB token)
  • the pcsc pkcs11 Win­dows DLL is not suit­able yet for use on Win­dows 8 64bit
  • I con­tacted the card reader ven­dor if the card reader or the dri­ver is the prob­lem regard­ing the extended APDUs
  • I found prob­lems in gpg4win / pcsc on Win­dows 8
  • I have send some money to the devel­op­ers of gpg4win to sup­port their work (if you use gnupg on Win­dows, try to send a few units of money to them, the work stag­nated as they need to spend their time for paid work)

So either I need a new card reader, or have to wait for an update of the linux dri­ver of the ven­dor… which prob­a­bly means it may be a lot faster to buy a new card reader. When look­ing for one with at least a PIN pad, I either do not find any­thing which is listed as sup­ported by pcsc on the ven­dor pages (it is incred­i­ble how hard it is to nav­i­gate the web­sites of some com­pa­nies… a lot of buzz­words but no way to get to the real prod­ucts), or they only list updated mod­els where I do not know if they will work.

When I have some­thing which works with FreeBSD and Win­dows, I will pub­lish all the HOW­TOs here at once.

GD Star Rat­ing
GD Star Rat­ing


Com­plete net­work loss on Solaris 10u10 CPU 2012-10 on vir­tu­al­ized T4-2

The prob­lem I see at work: A T4-2 with 3 guest LDOMs, vir­tu­al­ized disks and net­works lost the com­plete net­work con­nec­tiv­ity “out of the blue” once, and maybe “spo­radic” directly after a cold boot. After a lot of dis­cus­sion with Ora­cle, I have the impres­sion that we have two prob­lems here.

1st prob­lem:
Total net­work loss of the machine (no zone or guest LDOM or the pri­mary LDOM was able to have receive or send IP pack­ets). This hap­pened once. No idea how to repro­duce it. In the logs we see the mes­sage “[ID 920994 kern.warning] WARNING: vnetX: exceeded num­ber of per­mit­ted hand­shake attempts (5) on chan­nel xxx”. Accord­ing to Ora­cle this is sup­posed to be fixed in 148677 – 01 which will come with Solaris 10u11. They sug­gested to use a vsw inter­face instead of a vnet inter­face on the pri­mary domain to at least lower the prob­a­bil­ity of this prob­lem hit­ting us. They were not able to tell us how to repro­duce the prob­lem (seems to be a race con­di­tion, at least I get this impres­sion based upon the descrip­tion of the Ora­cle engi­neer han­dling the SR). Only a reboot helped to get the prob­lem solved. I was told we are the only client which reported this kind of prob­lem, the patch for this prob­lem is based upon an inter­nal bugre­port from inter­nal tests.

2nd prob­lem:
After cold boots some­times some machines (not all) are not able to con­nect to an IP on the T4. A reboot helps, as does remov­ing an inter­face from an aggre­gate and directly adding it again (see below for the sys­tem con­fig). To try to repro­duce the prob­lem, we did a lot of warm reboots of the pri­mary domain, and the prob­lem never showed up. We did some cold reboots, and the prob­lem showed up once.

In case some­one else sees one of those prob­lems on his machines too, please get in con­tact with me to see what we have in com­mon to try to track this down fur­ther and to share info which may help in maybe repro­duc­ing the problems.

Sys­tem setup:

  • T4-2 with 4 HBAs and 8 NICs (4 * igb on-board, 4 * nxge on addi­tional net­work card)
  • 3 guest LDOMs and one io+control domain (both in the pri­mary domain)
  • the guest LDOMs use SAN disks over the 4 HBAs
  • the pri­mary domain uses a mir­rored zpool on SSDs
  • 5 vswitch in the hypervisor
  • 4 aggre­gates (aggr1 — aggr4 with L2-policy), each one with one igb and one nxge NIC
  • each aggre­gate is con­nected to a sep­a­rate vswitch (the 5th vswitch is for machine-internal communication)
  • each guest LDOM has three vnets, each vnets con­nected to a vswitch (1 guest LDOM has aggr1+2 only for zones (via vnets), 2 guest LDOMs have aggr 3+4 only for zones (via vnets), and all LDOMs have aggr2+3 (via vnets) for global-zone com­mu­ni­ca­tion, all LDOMs are addi­tion­ally con­nected to the machine-internal-only vswitch via the 3rd vnet)
  • pri­mary domain uses 2 vnets con­nected to the vswitch which is con­nected to aggr2 and aggr3 (con­sis­tency with the other LDOMs on this machine) and has no zones
  • this means each entity (pri­mary domain, guest LDOMs and each zone) has two vnets in and those two vnets are con­fig­ured in a link-based IPMP setup (vnet-linkprop=phys-state)
  • each vnet has VLAN tag­ging con­fig­ured in the hyper­vi­sor (with the zones being in dif­fer­ent VLANs than the LDOMs)

The pro­posed change by Ora­cle is to replace the 2 vnet inter­faces in the pri­mary domain with 2 vsw inter­faces (which means to do VLAN tag­ging in the pri­mary domain directly instead of in the vnet con­fig). To have IPMP work­ing this means to have vsw-linkprop=phys-state. We have two sys­tems with the same setup, on one sys­tem we already changed this and it is work­ing as before. As we don’t know how to repro­duce the 1st prob­lem, we don’t know if the prob­lem is fixed or not, respec­tively what the prob­a­bil­ity is to get hit again by this problem.

Ideas / sug­ges­tions / info welcome.

GD Star Rat­ing
GD Star Rat­ing


Which crypto card to use with FreeBSD (ssh/gpg)

The recent secu­rity inci­dent trig­gered a dis­cus­sion how to secure ssh/gpg keys.

One way I want to focus on here (because it is the way I want to use at home), is to store the keys on a crypto card. I did some research for suit­able crypto cards and found one which is called Feit­ian PKI Smart­card, and one which is called OpenPGP card. The OpenPGP card also exists in a USB ver­sion (basi­cally a small ver­sion of the card is already inte­grated into a small USB card reader).

The Feit­ian card is reported to be able to han­dle RSA keys upto 2048 bits. They do not seem to han­dle DSA (or ECDSA) keys. The smart­card quick starter guide they have  (the Tun­ing smart­card file sys­tem part) tells how to change the para­me­ters of the card to store upto 9 keys on it.

The spec of the OpenPGP card tells that it sup­ports RSA keys upto 3072 bits, but there are reports that it is able to han­dle RSA keys upto 4096 bits (you need to have at least GPG 2.0.18 to han­dle that big keys on the crypto card). It looks to me like the card is not han­dle DSA (or ECDSA) cards. There are only slots for upto 3 keys on it.

If I go this way, I would also need a card reader. It seems a class 3 one (hard­ware PIN pad and dis­play) would be the most “future-proof” way to go ahead. I found a Reiner SCT cyber­Jack sec­oder card reader, which is believed to be sup­ported by OpenSC and seems to be a good bal­ance between cost and fea­tures of the Reiner SCT card readers.

If any­one read­ing this can sug­gest a bet­ter crypto card (keys upto 4096 bits, more than 3 slots, and/or DSA/ECDSA  sup­port), or a bet­ter card reader, or has any prac­ti­cal expe­ri­ence with any of those com­po­nents on FreeBSD, please add a comment.

GD Star Rat­ing
GD Star Rat­ing


ICS on the Sam­sung Galaxy Tab 10.1

Last week I had a look if there are some news for an offi­cial update of the Galaxy Tab 10.1 to ICS. To my sur­prise there is one at least in Italy. The one I found to down­load was marked more or less for the Euro­pean mar­ket. Well… that was good enough for me and the night from Fri­day to Sat­ur­day I have spend to update the Tab by hand (unfor­tu­nately this includes a fac­tory reset, no smooth migra­tion from an old ver­sion, but at least I still have root access).

What I noticed so far:

  • OpenGL ES speed improved from 4.2 to 6.6 FPS.
  • I had some lock-ups so far, I do not know if this may be related to some restored data (app data and e.g. Bluetooth/WLAN con­fig restored with Tita­ni­um­Backup) or to bugs (Dalvik cache and cache par­ti­tion where clean, fac­tory reset was done too prior to restor­ing from the backup). I had to press the power but­ton for some sec­onds to ini­ti­ate a reboot. Most of the time it helped to wait a minute before enter­ing the PIN for the SIM. One time it did not help at all, the only way to get it work­ing was to take my WLAN Access Point (AP) offline, start the Tab, enter the PIN, and to restart the AP. At that point I had GPS and WLAN in the Tab acti­vated, in the lock-ups before I did not have GPS active. I had some­thing sim­i­lar like this with my Nexus S when it got ICS, some­how this resolved itself. Update 2012-08-14: I googled a bit, there was a bug in ICS 4.0.3 related to WLAN, but I have 4.0.4 on the Tab, so this may not be this. I also got the freeze with­out WLAN but with the mobile data con­nec­tion active. 2nd update 2012-08-14: If I dis­able account sync­ing with the mobile data con­nec­tion it does not freeze. I have not yet tried this with the WLAN con­nec­tion. Update 2012-08-16: The syn­chro­niza­tion of the cal­en­dar data caused the prob­lem. Delet­ing all data for any app with cal­en­dar in the name and re-syncing fixed the prob­lem. No freeze since I did this yesterday.
  • When I open/close a folder (much missed fea­ture in Android 3.x), the Tab speaks with me (some­thing like “Folder XXX opened” in the con­fig­ured lan­guage… that is a bit annoying).
  • I like the default back­ground image.
  • Update 2012-08-14: The bat­tery icon does stay green even when the bat­tery is nearly empty. :(

I was not able to test the Email APP yet, I am wait­ing for a warranty-replacement of the PSU of my server at home (Murphy’s law: Your PSU will break when you just started a big ren­o­va­tion of your kitchen and do not have time to take care about it, and when you get time a lot of peo­ple from the PSU-manufacturer which take care about warranty-replacements are in holiday).

I also need to check the mobile data con­nec­tiv­ity (qual­ity and speed), but I would expect that it is not worse than before. Update 2012-08-14: The down­load speed test shows sim­i­lar results than before, the upload speed test is slower, but this may be the mobile net­work here where I tested. At least I can con­firm that it works, mod­ulo the prob­lem of the freezes described above.

GD Star Rat­ing
GD Star Rat­ing

Tags: , , , , , , , , ,

Web­Sphere 7: solu­tion to “pass­word is not set” while there is a pass­word set

I googled a lot regard­ing the error mes­sage “pass­word is not set” when test­ing a data­source in Web­Sphere (, but I did not find a solu­tion. A co-worker finally found a solu­tion (by accident?).

Prob­lem case

While hav­ing the appli­ca­tion JVMs run­ning, I cre­ated a new JAAS-J2C authen­ti­ca­tor (in my case the same login but a dif­fer­ent pass­word), and changed the data­source to use the new authen­ti­ca­tor. I saved the con­fig and syn­chro­nized it. The files config/cells/cell­name/nodes/node­name/resources.xml and config/cells/cell­name/secu­rity.xml showed that the changes arrived on the node. Test­ing the data­source con­nec­tiv­ity fails now with:

DSRA8201W: Data­Source Con­fig­u­ra­tion: DSRA8040I: Failed to con­nect to the Data­Source.  Encoun­tered java.sql.SQLException: The appli­ca­tion server rejected the con­nec­tion. (Pass­word is not set.)DSRA0010E: SQL State = 08004, Error Code = –99,999.

Restart­ing the appli­ca­tion JVMs does not help.


After stop­ping every­thing (appli­ca­tion JVMs, nodeagent and deploy­ment man­ager) and start­ing every­thing again, the con­nec­tion test of the data­source works directly as expected.

I have not tested if it is enough to just stop all appli­ca­tion JVMs on one node and the cor­re­spding nodeagent, or if I really have to stop the deploy­ment man­ager too.

GD Star Rat­ing
GD Star Rat­ing

Tags: , , , , , , , , ,