2016/09/09(金)H8/3069F ROMライタの制作

2016/08/10 の記事 で紹介した道具を、特注で製作しなければならないことになり(というか当初の作業工程策定で漏れていた)、急遽現在のファームウェア制作を数日中断して作ることにしました。

その部品たちの一部が以下:
20160910.JPG

来週半ば目途に完成させないとならないという、半ば突貫工程です。。
と言っても、プリント基板さえ作ってしまえば、1~2日程度で出来そうな規模ですが。。

2016/08/16(火)BCD ⇔ 符号なしバイナリ変換

システム制御系、特にファームウェア制作ではよく出てくるにも関わらず、
毎回調べ直すという非効率なアホ作業をしでかしているので、自分メモ的にまとめてみようと・・orz

BCD コードというのは Binary Coded Decimal の頭文字で、日本語の古い文献などには「二進化十進数」とも表記されます。
数字を表示する機器などには未だ広く使われているようです。
BCDコードとバイナリコードの相違が理解できない方は、まずそれを他所で理解してください。理解できていないと、以下の記事の内容は全く理解できないでしょう。

今般の制作ボードの中にBCDコードを要求するLSIがあり、BCDコードとバイナリコードの相互変換が必要です。必要なのは 0~99の値なので、それに特化しています。

難しいのは、バイナリ → BCD変換のほうで、実に力ずくのアルゴリズムから、難解なものまでいろいろな方法があるのですが、応用が利くのは以下の、
『BCD部分の各桁について、「値が5以上ならば3を加算する」』
を基本にする手法。
以下を参考にしています:
http://www.geocities.jp/leitz_house/electronics/pic/bcd_01.htm
http://minkara.carview.co.jp/userid/526128/blog/24236882/
〔覚え書き:2進数 ⇒ BCD変換について…〕

オリジナルは、どうやらキャッシュしか残っていないようで、いつ消えるか判りません。
こんな方法で本当に出来るのか? という疑問を持たれる方が大半と察しますが、数学的見地でも本当に出来るのですから、科学の基礎というのは奥が深いです。
実際にC言語にて作ったものが以下(ビックエンディアン環境にて動作確認済):
/**  cnv_byte_to_bcd 1バイトバイナリデータを1バイトBCDに変換 */
unsigned char cnv_byte_to_bcd(unsigned char bval) {
  union {
    struct {
      unsigned char bcd ;          // 変換後の値
      unsigned char hex ;          // 変換対象バイナリ
    } conv ;
    unsigned short  buf ;
  } convbcd ;

  unsigned char bitcnt ;

  if (bval >= 100) return (bval) ; // バイナリ値 100 以上は BCD に変換不可のため、そのままリターン。
  convbcd.buf = 0 ;                // 使用領域は予めゼロクリアしておく。
  convbcd.conv.hex = bval ;        // 変換対象のバイナリ値を置数。

  for (bitcnt = 0 ; bitcnt < 8 ; bitcnt++) {
    if (((convbcd.conv.bcd & 0x0f) + 0x03) >= 0x08) convbcd.conv.bcd += 0x03 ;
    if (((convbcd.conv.bcd & 0xf0) + 0x30) >= 0x80) convbcd.conv.bcd += 0x30 ;
    convbcd.buf <<= 1 ;
  }
  return convbcd.conv.bcd ;
}
肝になる部分は、union 共用体の部分で、メンバ bcd と メンバ hex の順番は重要です。
対象ターゲットCPUは、ビックエンディアンで、その環境で動作確認しています。
インテルやAMDのCPUだと、殆どがリトルエンディアンなので、メンバ bcd と メンバ hex の定義を逆にしないと駄目かもしれません。

一方で、BCD → バイナリ変換は簡単です。4ビットごとに区切り、上位4ビットの値を×10し、下位4ビットをそのまま加算すると変換完了です。
/**  cnv_bcd_to_byte 1バイトBCDデータを1バイトバイナリに変換 */
unsigned char cnv_bcd_to_byte(unsigned char bval) {

  unsigned char convbin ;

  convbin = ((bval & 0xf0) >> 4) * 10 + (bval & 0x0f) ;
  return convbin ;
}

2016/08/10(水)新たな制御ボードの制作/開発作業

今回の作業に欠かせない道具ですが、高密度・小型化の影響で従来のものと物理的なインタフェースが全く異なるため、新規に自作することから始まりました。

左側が従来のもの、右側が自作したもの。
どういう道具かというと、制作/開発ターゲットになる制御基板に搭載するプログラム(これをファームウェアと言います)をパソコンから転送したり、起動・停止制御したりする道具です。
20160810_1.jpg20160810_2.jpg

このように接続し、埋め込むプログラムを制作していきます。
制御基板の企画やハードウェア設計から当方が手掛け、ある程度設計を終えていたので、1カ月で終われるといいのですが、無理っぽいです。。orz
ちなみに、市販はしていませんし、今のところ市販の予定はありません。
NTTで光回線ルータをレンタルするのと似たような感じです。
(話だけはありますが、どう商品化するのか・・・が問題ですね)
20160810_3.jpg

2016/08/06(土)プライベートCAの構築[FreeBSD] (3)

2017/10/12 19:35 サーバ運営・管理
このシリーズのその1 → プライベートCAの構築[FreeBSD] (1)
このシリーズのその2 → プライベートCAの構築[FreeBSD] (2)

自分メモですが、証明書の失効方法や、証明書には種類があるというお話です。

● 証明書の失効手続き
利用対象者が居なくなった場合とか、何らかの問題が起きた場合に発行した証明書を取り消したい(無効にしたい)場合があります。

そんな場合には、「証明書失効操作」を行います。
openssl ca -gencrl -revoke user.pem -out cert.crl
cert.crl が失効リストで、実際には証明書のシリアルナンバーと対応する証明書の失効日が暗号化(?)されて記述されたものが書き込まれるようです。
この cert.crl を各サーバ(Apache、OpenVPN等)の設定で参照するようにします。

これとは別に、証明書発行リストが以下のようにCA管理ディレクトリの index.txt に生成されます。
20160806_1.png
Vで始まる行は、現在有効な証明書、
Rで始まる行は、失効する証明書を示しています。

●証明書には種類がある。
多くの場合、ディジタル証明書といえば、サーバ証明書をさす場合が多いです。
Webサーバで https を行う場合や、電子メールサーバにて TLS 通信を行う場合は、必ず必要になるのでお馴染みの方も多いでしょう。

OpenVPN のクライアント側には、接続先のサーバ証明書(公開鍵のみ)のほかに、クライアント証明書というのが必要になります。
これを OpenSSL コマンドラインで発行するには、 FreeBSD では /etc/ssl/openssl.cnf の設定を一部変更する必要があります。
20160806_2.png

具体的には、[ usr_cert ] ブロックの nsCertType パラメータを
nsCertType = client, email, objsign
とする必要があります。
こうしないと、少なくとも OpenVPN は KU ERROR が発生したり、接続途上でダンマリを決め込んでしまい、クライアント側から上手く接続できません。

ですが、サーバ証明書の場合は、これでは逆に駄目で、
nsCertType  = server
とする必要があります。

2016/07/27(水)FreeBSD 10.3R 環境で dovecot 2.2.25 はそのままでは動作しない

2017/10/12 19:34 サーバ運営・管理
dovecot は、電子メール送受信サービスを実現する際に欠かせないサーバソフトウェアで、皆様が利用する多くのISPで採用されています。
弊社でも採用していますが、どうやら FreeBSD固有のバグがあるようです。
具体的には、
Last died with error (see error log for more information):
 kevent(EV_ADD, READ, 56) failed: Bad file descriptor
(実際は改行しません)

といったメッセージが起動時に発生し、サービスを全く提供出来なくなるという重篤な問題。
これは、日本語の情報がほぼ皆無ですが、以下のパッチで凌げます。(弊社でも確認済。)
#Ports でインストールする場合は、既にパッチが当たった状態でインストールされるので問題ありません。
画像をクリックすると見やすい大きさで表示されると思います。

20160728_1.png

20160728_2.png
〔参考URL〕 https://github.com/dovecot/core/commit/ffd8dc932516bc55bf01d91355540daab365e5e9

余りお勧めしませんが、次のバージョン 2.2.26 が出るのを待つ手もあります。

2016/07/17(日)プライベートCAの構築[FreeBSD] (2)

2017/10/12 19:33 サーバ運営・管理
前々回の記事 にて、プライベートCAの作り方のメモを書きました。

今度は、構築したプライベートCAを用いて、実際にサーバ証明書を発行するところまでメモしておきます。実際に発行する環境を整えるために、最初の一度だけ幾つか準備が必要です。

○ 準備その1- /etc/ssl/openssl.cnf の変更
以下のセクションを修正します。

[ usr_cert ]
basicConstraints=CA:false
(CA:true を CA:false に)

[ v3_ca ]
basicConstraints=CA:false
(CA:true を CA:false に)

これやらないと、証明書は発行できるものの、発行した証明書は不正証明書扱いになってしまいます。

○ 準備その2 - CA の公開証明書を pem 形式から der形式へ変換
# cd /root/BasekernelCA
# openssl x509 -in cacet.pem -inform PEM -out cacert.der -outform DER
ここで作成した der 形式の証明書ファイルを Webサイト公開ディレクトリ等に設置し、Webページからダウンロード出来るようにしておきます。

● いよいよサーバ証明書の発行
ここから先は、本物の認証局にサーバ証明書発行手続きをする際にもほぼ同じ手順が使用できます。但し、Unix系/Linux系のコマンドラインインタフェースが基本です。

○ 秘密鍵の生成
# openssl genrsa -out private.key 2048
この後生成する公開鍵とペアで使用されます。
ここでは 2048bit(256バイト) 長の秘密鍵を生成します。

一般的に「鍵長」とはこの秘密鍵の鍵長で、現在では 2048 bit 以上でないと、サーバ証明書発行を受け付けません。
また、-des3 や -aes128 などのパラメータを付加すると、パスフレーズ(パスワードと同じようなものだが、似て非なるもの)を付けることが出来ますが、サーバ用途においては却ってパスフレーズが邪魔になる(自動起動が できなくなる)ため、特に理由が無い限りは付けないほうがよいです。

○ CSR(署名申請書/Certificate Signing Request)の生成
# openssl req -new -sha512 -key private.key -out server.csr

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Hokkaido
Locality Name (eg, city) []:Sapporo
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Base Kernel Co,.Ltd.
Organizational Unit Name (eg, section) []:labo
Common Name (e.g. server FQDN or YOUR name) []:clione.basekernel.ne.jp
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
この手順で、当該の例では暗号化された CSR が server.csr ファイルに作成されます。
ここで・・・

Country Name - ここは日本なので、ISO3166 で規定され、日本を示す2レターコード JP を指定します。

State or Province Name - 日本では都道府県に該当し、米国では州、中共では省です。筆者の組織は北海道にありますので、そのまま Hokkaido とします。

Locality Name - 市区町村名。筆者の組織は札幌市にありますので、そのまま Sapporo とします。 Sapporo-shi や Sapporo City でも大丈夫なようですが、個人的には好みではありません。

Organization Name - 組織名。英語表記の正式名称を記述します。
本物の認証局に対し CSR を発行する際は、ドメイン登録情報と比較したときに、ここを一字一句間違えただけでも発行を拒絶されることがあります。

Organizational Unit Name - 組織内部署名。省略可能ですが、同一組織が複数のサーバ証明書を必要とする場合、ここに何等かの情報を記述し、区別する必要があります。

Common Name - サーバの場合は、サーバのFQDN 名、電子メール認証の場合は、証明対象の電子メールアドレスを記述します。

Email Address 以降は通常、省略します。

本物の認証局に証明書発行依頼をする際は、殆どの場合、この server.csr の中身(テキストファイルです)をコピー&ペーストする仕組みになっていると思います。

○ CA局による証明書(公開鍵)の発行
# openssl ca -out server.pem -infiles server.csr
この操作により、
Enter pass phrase for /root/BaseKernelCA/private/cakey.pem:
と、プライベートCAを生成するときに設定したパスワードを入力後、
下記のように確認が促され、
20160717.png

Sign the certificate? [y/n] の問いに y で署名処理、
1 out 1 certificate requests certified, commit?[y/n] の問いに y で登録処理
がなされ、証明書ファイル server.pem が作成されます。
このファイルの中身(暗号化されたテキストファイル)が証明書本体です。

2016/07/16(土)サトーパーツの端子台 ML-1800-S1-Pxx

2017/10/12 19:31 電子工作
プライベートCA関係の記事の予定でしたが、これも自分メモ。。

左側が32端子あるタイプの ML-1800-S1-P32 という型番の部品、
右側が 6端子あるタイプの ML-1800-S1-P6 という型番の部品。
DSCF5420.JPG

この端子台は、横にいくつでもレゴブロックのように連結することができます。
話には聞いていたし、どこかでそういう説明も見かけた記憶があるのですが、実際に見たことが無いし、メーカーのカタログ等に説明が無い。

と、いうことで、将来同じ疑問を持つかもしれない方々のために検証出来たので記録しておきます。
先ず、左端は簡単にカバーを外すことができます。
DSCF5422.JPG

カバーを外すと金属端子がむき出しになります。それを覆うためのカバーですね。
ここからが重要なのですが、この端子台は最小2端子単位で簡単に分解できます。
DSCF5423.JPG

なので、品番としては 32端子ものの ML-1800-S1-P32 が入手可能な端子数としては最大ですが、連結してあたかもひとつの大きな端子台として実装することができます。
これは 32端子ものと 6端子ものを合体させて、38端子を構成した様子です。
連結の際は、連結する側の左端のカバーを外します。
DSCF5424.JPG

ちなみに右端は常にこんな感じになります。
DSCF5425.JPG

連結のための凹部があります。

2016/07/15(金)プライベートCAの構築[FreeBSD] (1)

2017/10/12 19:30 サーバ運営・管理
現在、弊社サーバネットワーク内部のSSL通信に使用しているプライベートCAによるサーバ証明書が SHA-1 ベースのため、SHA-2 に移行すべく準備作業中です。
7年半前に構築したきりですので、構築手順を忘れています・・・orz
ということで、2回の記事に分けて投稿します。いつものメモです。

具体的には、弊社のVPN接続と電子メール送受信(TLS 又は SSL を使用している場合のみ)に影響があります。新しい証明書に入れ替えて頂く必要があります。

きちんとした正式認証局のものを使うべきだろう、、という声も聞こえてきそうですが、弊社暗号化通信サービスに閉じた用途ですし、逆に汎用的に使われては困るので、弊社プライベートCAでの運用としています。

● 先ずは、スクリプトの修正
Google先生の検索では、Linux ベースの CentOS の事例ばかりで、FreeBSD の事例はほぼ皆無。
ですが、ファイルの置き場所以外に大差ありません。
FreeBSD の場合は、 /usr/src/crypto/openssl/apps/CA.sh を編集します:
(63行目付近)
if [ -z "$DAYS" ] ; then DAYS="-days 395" ; fi  # 13 month
CADAYS="-days 14610"    # 40 years
REQ="$OPENSSL req $SSLEAY_CONFIG"
(71行目付近)
if [ -z "$CATOP" ] ; then CATOP=/root/BaseKernelCA ; fi
CADAYS はCAの有効日数。
CATOP はCAにて発行する証明書の管理トップディレクトリです。
共に適宜の値を指定します。

変更したら、
# chmod +x /usr/src/crypto/openssl/apps/CA.sh
として、スプリプトを実行可能状態にしておきます。

●次に /etc/ssl/openssl.cnf の修正
FreeBSD においては、opensslの設定ファイルは、/etc/ssl/openssl.cnf にあります。

このファイルは、セクション単位に設定項目がまとまっています。
セクション内の該当パラメータを以下のように修正します。
[ CA_default ]
dir             = /root/BaseKernelCA
default_days    = 7305
default_crl_days= 30
default_md      = sha512
policy          = policy_match

[ policy_match ]
countryName             = match
stateOrProvinceName     = supplied
organizationName        = supplied
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
default_bits            = 2048
default_md              = sha512

[ req_distinguished_name ]
countryName_default             = JP
stateOrProvinceName_default     = Hokkaido
0.organizationName_default      = Base Kernel Co., Ltd

[ usr_cert ]
basicConstraints=CA:true
nsCertType                      = server

[ v3_ca ]
basicConstraints = CA:true
nsCertType = sslCA, emailCA
この修正で、鍵長デフォルト 2,048bit、暗号化ハッシュ SHA-2(SHA512) に対応します。
修正したら、プライベートCAの構築です。(以下、一部テキスト伏字処理あり)
# /usr/src/crypto/openssl/apps/CA.sh -newca
CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 2048 bit RSA private key
...............................................................+++
.......................................+++
writing new private key to '/root/BaseKernelCA/private/./cakey.pem'
Enter PEM pass phrase:       (CAパスフレーズ入力)
Verifying - Enter PEM pass phrase: (もう一度同じCAパスフレーズ入力)
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]:      (JP でよいのでこのままリターン)
State or Province Name (full name) [Hokkaido]:(Hokkaido でよいのでこのままリターン)
Locality Name (eg, city) []:Sapporo
Organization Name (eg, company) [Base Kernel Co., Ltd]:
Organizational Unit Name (eg, section) []:Base Net
Common Name (eg, YOUR name) []:Base Kernel CA
Email Address []:hoge@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:   (このままリターン)
An optional company name []: (このままリターン)
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /root/BaseKernelCA/private/./cakey.pem:
Check that the request matches the signature
Signature ok
(以下省略)
実際には続いてこんな感じで詳細が出力されます:
20160715.png

この例では、/root/BasekernelCA/cacert.pem にCAの証明書が生成されます。
この証明書は、後でサーバ証明書を発行する際に、一緒にCA証明書として通知を行います。

また、この例では証明書の有効期間を 40年としていますが、こういうアホな証明書も発行できるということでご参考にどーぞ。

次の記事は、このプライベートCAを用いたサーバ証明書の発行方法です。
#以前は出来なかったんです。はい。確か、2036年くらいが限界でした。

2016/06/10(金)FreeBSD自身をコンパイルしてセルフ更新してみる

2017/10/12 19:27 サーバ運営・管理
(その1)
20160610_1.png
FreeBSD 9.3R , Athron64x2 3800+ Dual Core , DDR2 1024MByte , ATA100 80GB HDD
中古購入のため M/B 型番不明

(その2)
20160610_2.png
FreeBSD 10.1R , Athron64 3000+ , DDR 2048MByte , ATA100 80GB HDD
Asus A8V

(その2)のほうは、時間かかりすぎのような気がするのだが、、、
OSのバージョンも違うし、(その2)のほうは、役割上LANを4系統接続している状態だし、ハードウェアスペックも低いから単純な比較は出来ないけれど。。

それを差し引いてもねぇ。。です。どんなものでしょうか。

2016/06/02(木)ソフトウェア的なデバッグでは判らない不具合・・・

ソフトウェアの制作や開発作業をやっていると、一度や二度は不可解な問題に遭遇するものだが。。この件もそうでした。。。

何度チェックしてもコンピュータプログラム的には間違いがない。
だが、意図した動作にならない。
今回はディジタル信号で計測温度を取得する温度センサで、温度センサとやりとりする信号線の波形を観ないと原因が判らない。

こんなときはオシロスコープを使うのですが、どんなに安価なものでも20万円程度はする高価な測定機器で、業務上必要なのにもかかわらず、筆者の手元には未だに無いのです。
ほんと、腹立だしいのと情けないのと交錯する心境です。

ですが、使い古しのデジタルオシロスコープセットを貸してくれた同業者が居られたので、折角ですから、問題は既にハードウェア設計変更で解決してしまったのですが、原因を追ってみました。

具体的な機種名は一応伏せておきますが、15年くらい前にノート型パソコンとセットで発売された機種のようで、帯域10MHz、サンプリング周波数 100MHz のようです。
DSC_0222.JPG

波形が取れたら、原因はすぐわかりました。
「この温度センサーとこのハードウェアは直結できない」です。
具体的な話は専門分野な方々にしかわからない話になるので、コメントで質問していただければ、回答致します(^^)

やっぱり欲しいねぇ。。オシロスコープ。。。
今、手元にあるオシロスコープは返却しないといけませんからね。
今般の案件では問題ないけれど、無線周波数帯には使えないし、、