Well, the status so far:

• I have a HOWTO what to install to use crypto cards in FreeBSD
• I have a HOWOT what to install / configure in Windows
• I have a HOWTO regarding creating 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 support extended APDUs
• I want to make sure what I write in the HOWTOs is also suitable for the use with Windows / PuTTY
• it seems Windows needs a certificate and not only a key when using the Windows CAPI (using the vendor supplied card reader driver) in PuTTY-CSC (works at work with a USB token)
• the pcsc pkcs11 Windows DLL is not suitable yet for use on Windows 8 64bit
• I contacted the card reader vendor if the card reader or the driver is the problem regarding the extended APDUs
• I found problems in gpg4win / pcsc on Windows 8
• I have send some money to the developers of gpg4win to support their work (if you use gnupg on Windows, try to send a few units of money to them, the work stagnated 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 driver of the vendor… which probably means it may be a lot faster to buy a new card reader. When looking for one with at least a PIN pad, I either do not find anything which is listed as supported by pcsc on the vendor pages (it is incredible how hard it is to navigate the websites of some companies… a lot of buzzwords but no way to get to the real products), or they only list updated models where I do not know if they will work.

When I have something which works with FreeBSD and Windows, I will publish all the HOWTOs here at once.

1st problem:
Total network loss of the machine (no zone or guest LDOM or the primary LDOM was able to have receive or send IP packets). This happened once. No idea how to reproduce it. In the logs we see the message “[ID 920994 kern.warning] WARNING: vnetX: exceeded number of permitted handshake attempts (5) on channel xxx”. According to Oracle this is supposed to be fixed in 148677–01 which will come with Solaris 10u11. They suggested to use a vsw interface instead of a vnet interface on the primary domain to at least lower the probability of this problem hitting us. They were not able to tell us how to reproduce the problem (seems to be a race condition, at least I get this impression based upon the description of the Oracle engineer handling the SR). Only a reboot helped to get the problem solved. I was told we are the only client which reported this kind of problem, the patch for this problem is based upon an internal bugreport from internal tests.

2nd problem:
After cold boots sometimes some machines (not all) are not able to connect to an IP on the T4. A reboot helps, as does removing an interface from an aggregate and directly adding it again (see below for the system config). To try to reproduce the problem, we did a lot of warm reboots of the primary domain, and the problem never showed up. We did some cold reboots, and the problem showed up once.

In case someone else sees one of those problems on his machines too, please get in contact with me to see what we have in common to try to track this down further and to share info which may help in maybe reproducing the problems.

System setup:

• T4-2 with 4 HBAs and 8 NICs (4 * igb on-board, 4 * nxge on additional network card)
• 3 guest LDOMs and one io+control domain (both in the primary domain)
• the guest LDOMs use SAN disks over the 4 HBAs
• the primary domain uses a mirrored zpool on SSDs
• 5 vswitch in the hypervisor
• 4 aggregates (aggr1 — aggr4 with L2-policy), each one with one igb and one nxge NIC
• each aggregate is connected to a separate vswitch (the 5th vswitch is for machine-internal communication)
• each guest LDOM has three vnets, each vnets connected 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 communication, all LDOMs are additionally connected to the machine-internal-only vswitch via the 3rd vnet)
• primary domain uses 2 vnets connected to the vswitch which is connected to aggr2 and aggr3 (consistency with the other LDOMs on this machine) and has no zones
• this means each entity (primary domain, guest LDOMs and each zone) has two vnets in and those two vnets are configured in a link-based IPMP setup (vnet-linkprop=phys-state)
• each vnet has VLAN tagging configured in the hypervisor (with the zones being in different VLANs than the LDOMs)

The proposed change by Oracle is to replace the 2 vnet interfaces in the primary domain with 2 vsw interfaces (which means to do VLAN tagging in the primary domain directly instead of in the vnet config). To have IPMP working this means to have vsw-linkprop=phys-state. We have two systems with the same setup, on one system we already changed this and it is working as before. As we don’t know how to reproduce the 1st problem, we don’t know if the problem is fixed or not, respectively what the probability is to get hit again by this problem.

Ideas / suggestions / info welcome.

After searching around a little bit in the net I found a formula which is supposed to give a hint about the target filesize. Naturally this depends on the encoder (or even the encoder-version), the encoder settings and even the video.

The formula is at least a good hint for my use, so I wrote a script which calculates several filesize values for a given video (based upon the output of mediainfo, which the scripts expects in a file with the filename as an argument to the script). It calculates a CBR and a VBR value for a given video based upon the width, height and duration. It should work on all system with a POSIX compatible shell.

Example output for a video from my HD-ready cam, original filesize 1.8 GB:

Width: 1280, Height: 720, FPS: 50.000, Time: 1424, Motion: 2
Per second: 6451200.000 bps / 6300 Kibps
Total CBR: 1148313600 bytes / 1121400 KiB / 1095 MiB
Total VBR: 861235200 bytes / 841050 KiB / 821 MiB
Width: 1280, Height: 720, FPS: 50.000, Time: 1424, Motion: 3
Per second: 9676800.000 bps / 9450 Kibps
Total CBR: 1722470400 bytes / 1682100 KiB / 1642 MiB
Total VBR: 1291852800 bytes / 1261575 KiB / 1232 MiB
Width: 1280, Height: 720, FPS: 50.000, Time: 1424, Motion: 4
Per second: 12902400.000 bps / 12600 Kibps
Total CBR: 2296627200 bytes / 2242800 KiB / 2190 MiB
Total VBR: 1722470400 bytes / 1682100 KiB / 1642 MiB

There are 3 sections, the difference is the “motion” value. It is a kind of multiplicator depending on the amount of motion in the video. For the videos I made myself (family videos, and even some videos of volley ball games), the first section seems to be just fine. So I reduced the original MP4 file to about 50% (not visible here is the audio size, normally I copy the original audio unmodified).

For the curious ones, the formula is

width_in_pixels * height_in_pixels * fps * motion_value * 0.07

for the bps value. The CBR value is

bps * playtime_in_seconds / 8

and the VBR value is

3 / 4 * CBR_value.

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 suitable crypto cards and found one which is called Feitian PKI Smartcard, and one which is called OpenPGP card. The OpenPGP card also exists in a USB version (basically a small version of the card is already integrated into a small USB card reader).

The Feitian card is reported to be able to handle RSA keys upto 2048 bits. They do not seem to handle DSA (or ECDSA) keys. The smartcard quick starter guide they have  (the Tuning smartcard file system part) tells how to change the parameters of the card to store upto 9 keys on it.

The spec of the OpenPGP card tells that it supports RSA keys upto 3072 bits, but there are reports that it is able to handle RSA keys upto 4096 bits (you need to have at least GPG 2.0.18 to handle that big keys on the crypto card). It looks to me like the card is not handle 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 (hardware PIN pad and display) would be the most “future-proof” way to go ahead. I found a Reiner SCT cyberJack secoder card reader, which is believed to be supported by OpenSC and seems to be a good balance between cost and features of the Reiner SCT card readers.

If anyone reading this can suggest a better crypto card (keys upto 4096 bits, more than 3 slots, and/or DSA/ECDSA  support), or a better card reader, or has any practical experience with any of those components on FreeBSD, please add a comment.

Guys:

• Thanks a lot for the countless hours you invested to find and close the initial attack vector.
• Thanks a lot for the countless hours you invested to get the machines back to a well known state.
• Thanks a lot for the countless hours you invested to verify the source repository.
• Thanks a lot for the countless hours you invested to get back to a trusted package building environment.
• Thanks a lot for the countless hours you invested to get the “remaining” infrastructure (and everything else I forgot to mention) back into a good state.

Or in short: Thanks a lot for the countless hours you invested to get us from “we’re busted” to “we’re back”.

And last but not least, thanks for the decision to be better safe than sorry regarding our userbase (while it is the only way to handle something like this in a OSS project, I unfortunately think it has to be mentioned instead of taking it as an obvious decision).

P.S.: I use One-Time-Passwords.

Basically it just works. If you know ICS already, you more or less know how it is on the Galaxy Tab 10.1.

The calendar app is different, it is the Samsung app, not the native ICS one. I have a problem to sync it with the exchange-connector as it is in Horde 4, but I did not take the time to investigate the issue. My Nexus S connects just fine, so it must be some modification by Samsung which is causing the issue.

Sometimes the tablet hangs, and I have to shutdown by pressing the power button for some seconds. This only happens when connected via WLAN. When I start the tablet again, it will hang again if I am not fast enough to enter the PIN of the SIM, unlock the screen and to deactivate the WLAN. But even then it will hang after the deactivation of the WLAN. After rebooting the second time (with WLAN already deactivated), everything works again.

The email app is also stuttering sometimes. This happens when I open a folder with a lot of emails and the email app is trying to determine if there are attachments or not. Either the app is not multi-threaded, or it is not well done.

Apart from that it just works.

• Thank you for hand written responses, I did not get obvious automatic responses or canned responses (well, maybe they did some copy&paste for the RMA address and such, but each mail had at least a part which was not coming from copy&paste).
• Thank you for getting back to me within a reasonable time.
• Thank you for politely answering all my support requests.
• Thank you for being honest in your communication (slow handling of the repair due to people being in holiday, not because of missing pieces from suppliers or other excuses outside Enermax).

This is how the support shall be, unfortunately this is not always the case, but at least here it was. Thank you!

The other point I did not like about the 3.2-app was the folder list moved so that the inbox is first when returning to the list. Thank god this changed too.

The two big disappointing points I had about this app are mostly fixed in the ICS version.