燻製記録

11/20 ベーコン塩漬け開始。ジップロックに入れて、一週間の間、毎日上下をひっくり返しながら、塩漬け。

以下、材料。

豚バラ肉	350g
塩	12g
三温糖	3g
黒コショウ	3g
セージ	3g
ナツメグ	一振り
シナモン	一振り
ローレル	3枚

11/26塩抜き(8:30～14:30まで6時間程)。意外と塩が抜けないものです。

現在、風乾中（といっても冷蔵庫の中ですが）。うまく乾いてくれるといいのですが。

白色LEDを点灯させてみる

とあるプロジェクト(?)のために、乾電池一本で白色LEDを点灯する回路をお試しして見ました。

白色とか青色のLEDのVFは4V程あるので、乾電池一本では点灯できません。昇圧するようなドライバが必要となります。

世の中にはいろんな実装があるようですが、

• 発振回路とインダクタンスで昇圧する
• チャージポンプを構成する
• LTC3490のようなドライバICを使う（ストロベリーリナックスで売っているこれとか）
• 昇圧ICっぽいの(NJM2360とか)を使うのはLED点灯にはtoo muchな気がします。

ということで、秋月のキットにならって（というかそのまま）、発振回路とインダクタンスで行くことにしました。

回路

お。ついたぞ。

syncookiesとListenバックログとパケットロスト

たまにはLinuxネタを。

Listenバックログは、伝統的なUNIXの実装だと、SYN_RCVDとESTABLISHEDの両方のソケット数を数えますが、LinuxのそれはESTABLISHEDな状態の数だけを数えるようになっています(manを見よ)。

これは何でかというと、いわゆるSYN Flooding攻撃への対応として、Linuxはsyncookieを実装したことの副作用なのだと思います。syncookieを実装していると、SYNに対してSYN_ACK(COOKIE)を返すコストがほぼゼロ（メモリコストとしては）になるので、来たSYNにすべてSYN+ACKを返すことが可能です。
したがって、SYN_RCVDの数は数えても意味がなくなったので、それはListenバックログの数としてカウントしないようにした、ということのようです（厳密に言うと、tcp_max_syn_backlog個までは SYN_RCVD で受けて普通のSYN+ACKを返し、それを超えた分についてはsyncookieを返すという挙動になりますが)。

syncookieの利点は、基本的に来たものは攻撃パケットだろうが正当な(legitimateな)パケットだろうがすべて食って返事が出来る、ということにあるのだと思われます。
すなわち、伝統的な実装の場合、攻撃パケットと正当なパケットは平等にキューから溢れますが、syncookieだと「とりあえず全員に応答してみて、handshake-completing-ACK (最後のACK)を返して来たものだけ処理をする」ということができるので、正当なコネクション要求を落としにくくなる、というメリットがあるということですね。

なお、syncookieはRFC4987で議論されていて、やり過ぎだとかTCPオプション使えないじゃないかとか、syncacheの方が良いとか毀誉褒貶?があるようですが、実装された以上は、まあ仕方がありません。

---

さて、前述のように「Listenバックログの数がESTABLISHEDの数だ」ということになっているので、ESTABLISHEDな受付待ちセッション数に上限を掛けなければならない都合上、Linuxはhandshake-completing-ACKを（能動的に）落とすことがあります。これは上の話からも明らかで、Listenバックログを超えてESTABLISHEDなセッションが生まれそうになったら、そのタイミングでACKを落とさざるを得ないからです。逆に伝統的な実装であれば、SYN+ACKを返した暁には、必ずhandshake-completing-ACKを受けることができます。

(余談ですが、LinuxはSYNも静かに、すなわちnetstatや/procに何らかの主張をすることなく落とすことがあって、ちょっと嫌ですね)

ここで問題になるのは、handshake-completing-ACKを落とすと、「クライアント側がESTABLISHEDなのに、サーバ側はSYN_RCVDのまま」といったことがあり得て、特に、クライアント側がread-sideになる場合は、(自分でkeep aliveなりselectなりでタイマーを掛けていない限り)無限に待ってしまうことがあり得ます。

さらに微妙なケースで、SYN+ACK再送とFIN再送のタイミングによっては、サーバ側も（read-sideの場合は、そして普通はサーバがread-sideになります）ESTABLISHEDのままになってしまうことがあり得ます。

一般論として、カーネルがパケットをいつ落とそうが知ったことではないわけですが、Linuxの場合、それが比較的、能動的な形で起きるので、そこはちょっとびっくりします。

---

何にせよ、

• タイマは掛けよう。
• tcp_abort_on_overflowやtcp_synack_retriesとかを使うのも良い考えかもしれない。
• syncookieの有無にかかわらず、Listenバックログは適切に設定すべし。

といったことに注意が必要ですね、というお話でした。

とってんぱらりのぷう。

フォーカシングスクリーン

ブロクを書くのを忘れていましたが、EOS kiss x3用のフォーカシングスクリーンを購入しました。

x3の標準のフォーカシングスクリーンは、ピントの山が掴みにくいと言われています（そもそもファインダーはペンタプリズムではなくてダハミラーだし）。中級機以上だと、いろんな交換用のフォーカシングスクリーンが用意されていて、適宜交換できるのですが x3 はエントリー機なので固定式です。

とはいえ、別にビッタリくっつけて固定されているわけではなくて、単に「交換するつもりで作っていない」「そもそもx3用サイズの純正スクリーンがない」だけで、頑張れば交換可能です。

こういうのはだいたい海外のベンチャーみたいなところが取り扱っていて、有名どころはKatzEye OpticsやFocusingScreenですが、色々考えた挙句に後者で購入しました。
台湾メーカなので欧米よりは近いとはいえ、8/16(火)に注文して、8/19には到着したので、都合4日です。優秀な発送といえるのではないでしょうか?

購入したスクリーンはK3というNIKON用のスクリーンをx3用に改造したものです。

スモーカー

スモークハウス(燻家)に飽きたらず、結構本格的な燻製器(スモーカー)を買い求めました。アマゾンで1万円を超える久々の工具、、、じゃなくて料理道具です。

Zwilling ツインスペシャルズ スモーカーセットです。
これ、大きさが28cmもあって、この手の鍋にしてはいろいろな物が乗せられます。

あと一緒に燻製大辞典も購入しました。手順書重要。

じゃじゃん！