CONBU, イベント, インフォメーション, コラム, ツール

あけましておめでとうございます。実は今年初のブログです。
本年もよろしくお願いします。

先日CONBUの一員として取材を受けた内容が、日経NETWORKの最新号の「ネット管理のお助けツール」という特集記事で取りあげられています。

日経NETWORK2017年3月号
http://ec.nikkeibp.co.jp/item/backno/NN0203.html

我々が紹介した、手作りネット構築の便利ツール、は以下になります。

  • 譜面台
  • トランシーバーアプリ
  • 静電気で貼り付くホワイトボードシート
  • カーペット用ケーブルガード
  • マグネットフック
  • ゴムシート
  • 六輪台車
  • 隙間用LANケーブル
  • はがしやすいラベルシール
  • 360度カメラ
  • 面ファスナーテープ
  • 深めの折り畳みコンテナー
  • タグ付きのケーブルバンド
  • 外付けのNIC
  • 無線LAN調査機器

ネットワーク技術情報紙とは思えないものが並んでますね。
場違い感半端ない感じです。
でもそれぞれ便利なんですってば!!
便利そうなグッズを街で見かけたら、それどこで買ったの?、その道具の名前は何?、と遠慮せずに聞いちゃうのが情報集めのコツです。
深めの折り畳みコンテナは電車の中で釣りに行くおじさんからアイリスオーヤマで買えることを教えてもらい、スーパーマーケットの中の人に六輪台車の品名を教えてもらいました。

実際にこれらの道具が使われている様子は、CONBUがお手伝いしているイベント会場で見ることができますので、良かったら足を運んでみてくださいませ。

直近だと、DroidKaigi 2017、Elixir Conf Japan 2017 でお手伝いをさせていただきます。

DroidKaigi 2017
https://droidkaigi.github.io/2017/

Elixir Conf Japan 2017
http://www.elixirconf.jp/

 

残念ながら紙面に載ってないけど使うと楽しい道具は他にもあります。
過去のツチノコブログにも登場したモノを2つほど上げておきます。


ガフガン(GAFFGUN)

長いケーブルを一気に床養生できる凄いヤツです。

ケーブル養生の秘密兵器、GAFFGUNを使ってみた
http://tsuchinoko.dmmlabs.com/?p=1708

CONBU ライブ設営 @ YAPPC:Assia Tokyo 2015
https://www.youtube.com/watch?v=C8KR9W5JPfQ

大きめの会場で長い距離を一気に養生するときにはとても便利なんですよね。

とはいえ問題点がいくつかあるので、今回の紙面からは落選しました。

  • 使うのにちょっとコツがいる。
  • ベタっと貼られちゃうので撤収がしにくい
  • 床養生禁止の会場等もあり、使える場所を選ぶ
  • 面養生が必要なケースはそれほど多くない
  • 人が通るような場所をしっかり養生する場合にはゴムシート等の別の道具で養生するほうが良い
  • 使ってると楽しくなってきちゃって、使うことが目的になってきちゃう。

ウォーキングメジャー

コロコロ転がすと距離が測定できる道具です。

ツチノコNOC JANOG39会場下見に行ってきました
http://tsuchinoko.dmmlabs.com/?p=4877

ツチノコNOC〜会場ネットワーク構築下見編〜
http://tsuchinoko.dmmlabs.com/?p=4839

これも以下の理由で今回の紙面からは落選してしまいました。

  • 会場から提供される図面に距離がきちんと入っていることが多く測定が必要ないことが多い
  • 使ってると楽しくなってきちゃって、測定に夢中になって他の大事なことを見落としちゃうことがある。

使って楽しい道具のほうがもちろん良いのですが、楽しすぎて手段が目的化しちゃうのは良くない、ってことですねえ。
我々は使って楽しい便利な道具を引き続き募集中です。

イベント, コラム, 数学

この記事は、数学カフェ_4次元コンテンツ出展の記録 Advent Calendar 2016 の、13日目となる記事です。
こんにちは。バーテンツチノコ(仮) の近藤です。
六本木のBARで夜な夜な、コードは書くけどカクテルは作れないバーテンダーをやっています。

私は今年、数学カフェのメンバーとして、11月5, 6日のサイエンスアゴラに出展をしてきました。
(※個人での参加であり、いかなる所属団体・DMMと関係ありません)
(※当記事は研究された事実を示すものではなく、実験中の試みになります)

こちらが展示の様子です。

何だか椅子に座ってヘッドマウントディスプレイを被っている人がいたり、
「4次元を見てみよう」というタイトルと、ポスターにたくさんの文字が書いてあったり。
ヘッドマウントディスプレイは、被ると立体が目の前に出現したりするのですが、それらだけ1人で見ても「???」ですよね。

コンテンツを展示するにあたっての口頭説明(接客)は必須です。

というわけで、本日は、「サイエンスアゴラ 出展当日の口頭説明」というテーマでブログを書きます。
実際にブースに遊びに来たようなつもりになってお付き合いいただければ幸いです。

====================

まず、「立体視」とは、どういう仕組みでしょうか。

私たちが目でものを見るときは、2次元の像しか見えないにも関わらず、目で見ているものがどんな立体なのかを知覚することが出来ます。

 

以下の像1枚だけを見ると、

赤で囲んだ面を手前と見た「立方体」か、黄色で囲んだ面を手前と見た「ちょっと歪んだ6面体」かの2通りに見えてしまいます。

これを「立方体」に見るためにはどうすれば良いでしょうか。

ものが立体に見える要因はいくつかありますが、影響が大きい要因を紹介します。


■左右の目の視差

試しに、何か物体を目の数十cm前に用意して、右目と左目を片目ずつパチパチつぶって見てみると、目の位置のズレから、同じものを見ているのに違う像が見えるはずです。

たとえばサイコロであったら、同じ場所にあってもそれぞれの目にはこんな風に違う像に見えたのではないでしょうか。

    

(※ちなみに、↑の画像で、「交差法」での立体視ができます)

私たちは、その2つの視点の差から情報を得て、頭の中で奥行きを認識します。

★ポイント: 左目と右目でそれぞれで別の角度から立体の像を見ると、脳内ではひとつの立体に見えます
では、同じように2つの目でものを見るときに。
現実に両目で見た時のように3次元上の距離の視差を作るだけではなく、4次元の方向(!)にも少しだけ視差を作ってものを見たとしたらどうなるでしょうか。

4次元な立体視(!?)が出来るのでは?

そんな仮説も入れ、今回の展示物は作成されました。

======

では、4次元の方向に傾けるというのはどういうことでしょう。

 

まずこちらの折り紙。

壁(2次元)に画鋲ではりつけてくるくると回すと。
角度が変わっていくけど、形は変わらず正方形ですね。

では同じ折り紙を、1次元上げて3次元空間上でくるくる回すとどうなるでしょうか。

正方形だった折紙が、ゆがんで台形になっていきます

(※↑の画像でも、「交差法」での立体視ができます)

 

次に1次元あげてこちらのサイコロ。

3次元上でくるくると回すと。
角度は変わっていくけど、形は変わらず立方体ですね。

では同じサイコロを、1次元あげて4次元空間上でくるくる回すとどうなるでしょうか。

折り紙のときと同じように、
立方体だったサイコロが、ゆがんで四角錐台になっていきます

(※↑の画像のように立体物が並んでいれば、「交差法」での四次元立体視が・・・出来るかも!?)

 

今回の展示物であるOculus Riftは、装着すると3次元の物体と4次元の物体が表示され、そのとき視点があたっている物体をゲームコントローラで操作してぐりぐり回転させることが出来るというものでした。

「回転」とは。先ほどサイコロをくるくる回したような3次元空間上での回転ボタンとは別に、今回は四次元の方向へ回転させるためのボタンと、左目と右目それぞれに見える物体を変化させ、四次元の立体感を出していくためのレバーを準備しました。

レバーは、NINTENDO 3DSの右についている、立体感を調節するためのレバーをご想像いただくと、わかりやすいかと思います。両目の距離を、4次元の方向に離していきます。

レバーを調節することで、従来の立体視とは違い、左目と右目にそれぞれ、「同じ形なんだけど4次元の方向にずれていく物体」が見えます。

4次元の方向にずれる時のサイコロが立方体から四角錐台になるような動きは、3次元仕様の脳をもつ私たちには直感的ではない動きですし、明らかに別の物体である「立方体」と「四角錐台」を両目ばらばらに見ることも大分気持ち悪い感じです。

ですが、その四次元方向にずれた「左目に見える物体」と「右目に見える物体」を無理やり同じ物体と思いこんで見てみることで、四次元のずれはこういうことなんだな、と認識することが出来れば・・・そんな期待を持って開発しました。

実物は、現在どこかに展示しているわけではないので見ることは出来ませんが、また発表の機会がありましたら、是非体験しに来てください。

以上、視覚から4次元を体感してみよう!といった展示での口頭説明でした。
たまたま持っていた小道具(折り紙やルービックキューブ)を使って、なるべく理解しやすく説明するよう努めました。

最後に個人の感想を書きますと、両眼の視差で四次元立体視が本当に出来るのかどうかは、いまだに半信半疑ではありますが、
VRを用いて4次元物体や3次元物体を4次元空間上で眺め続けること、自分で自由に操作することで、高次元への理解がより深まったと感じております。

素敵な企画に関わることが出来てよかったです!

ご協力いただいた方、ご来場くださった方、どうもありがとうございました!!!

コラム, 小ネタ

そろそろ忘年会シーズンです。
PPAP、練習してますかー?

ちなみにPPAPというのは、HPの独自プロトコルです。
詳細は以下を読んでください。

PPA – HP Printing Performance Architecture
http://www.undocprint.org/formats/page_description_languages/ppa

 

英語は苦手ですよね?
最近パワーアップしたというGoogle翻訳を使ってみました。

PPAPをGoogle翻訳

英語

The PPA protocol is actually composed of two protocols: a lower-level packet protocol called VLink and the Sleek Control Protocol (SCP). The VLink protocol regulates all data transferred back and forth between the printer and the computer. SCP sends command sequences to tell the printer to do things like load a sheet of paper, eject, and print a sweep.

Although PPA is a bi-directional protocol, I have mainly concentrated on its uni-directional component. It is not required for the host to be aware of the bi-directional nature of the device, which makes this easy to do.

All values are stored in big endian format.

日本語

PPAプロトコルは実際には、VLinkと呼ばれる低レベルパケットプロトコルとSCP(Sleek Control Protocol)という2つのプロトコルで構成されています。 VLinkプロトコルは、プリンタとコンピュータ間で転送されるすべてのデータを制御します。 SCPは、コマンドシーケンスを送信して、プリンタに用紙のセット、取り出し、掃引などの処理を指示します。

PPAは双方向プロトコルですが、私は主にその一方向コンポーネントに集中しています。 ホストがデバイスの双方向性を認識することは必須ではありません。このため、これを簡単に行うことができます。

すべての値はビッグエンディアン形式で格納されます。

 

ほぼ完璧な翻訳。
Google翻訳すげー、というネタでした。

忘年会で無駄な小ネタを披露してツルツル滑って欲しいな、と願っています。

ICTSC, イベント, コラム, ネットワーク

こんにちは、saiです。
「NTT西日本杯」第6回 ICTトラブルシューティングコンテスト(以下、トラコン)にて運営委員を務めさせて頂きました。

第6回トラコンでは15問の問題が学生の手によって出題されました!

今回は、私が担当した問題の内一つを紹介していきます。

タイトル:調子が悪いんでしょうか?

問題文

ある日、AWS内で弊社のWebサーバを稼動させることになりました。
ただしネットワークに割ける予算が少なかったために古いネットワーク機材を使用しています。
先日、本格稼動をする前に複数人で確認したところ、どうにも「見れるページ」と「見れないページ」が存在するようです。
また、状況によっては「見れないページ」も「見れる」場合があるそうです。
早急に原因を解明し、誤った設定内容を修正してください。修正後、報告もお願いします。
尚、変更するのはサーバのみでお願い致します。

見れないページ : URL

ServerIPaddress : ****
認証情報 【ID】: ****
【Password】: ****

FirewallIPaddress : ****
認証情報 【ID】: ****
【Password】:****


** 補足
問題を起こしている箇所を修正し、原因と修正内容を報告できれば対策を行えたものとします。*1

 *1  どういう状態になるとゴールなのかを記載していなかった為。又、全ての環境でMTUキャッシュクリアの方法をMTUというワードを出さずに周知できなかった為、補足させていただきました。

 

問題解説

この問題は、問題文と各種設定から原因を見つけていく問題でした。
AWS関連の情報やMTUについて詳しく知っていればピンとくるかもしれない問題ですが、そうでない場合難しい問題となったかもしれません。
また、解く際にWiresharkを用いたりすれば、MSS値周りの情報からヒントを見つける事が可能でした。

 

キーポイント

  • AWSのデフォルトMTU値が9001である
  • FW(vyosA)でicmpが全て拒否されている為、PathMTUDiscoveryまで拒否されている(PathMTUDiscoveryBlackhole問題)
  • 経路上のルータ(vyosB)のMTU値が800になっている
  • 結果、サイズが800byte*2を越えるWebページだけが見れなくなってしまう

  *2 実際には約600byte〜700byteくらい

 

解説

この問題では、一部Webページが見れない状況にありました。
その原因は、PathMTUDiscoveryが拒否されている事(PathMTUDiscoveryBlackhole)とMTUによってパケットがドロップしてしまう事でした。

まず前者についてですが、PathMTUDiscoveryはICMP type3 code4を用いMTUの低いルータ側から送信されます。
しかし、その先にあるファイアウォールがICMP全てをドロップしてしまう為、PathMTUDiscoveryが届かずデータの再送信が行われません。
その為、PCとAWS間のMSSが設定されたままパケットが送信され、途中経路のルータでパケットがドロップしてしまう状況が生まれます。

また、sshをすると通信の始めにクライアント側が大きいパケットを流すため、PathMTUDiscoveryがクライアント側に流れます。
そうすると、一時的にクライアント側のMTU値が800になるため、Webページを見れる状態になります。
しかし、これは恒久的な対策ではないため、これだけを解決策として報告した場合は間違いとなります。

今回、ファイアーウォールではなくサーバの設定を変更する問題となっているので、
サーバのMTU値を恒久的に800にあわせる設定を入れた事と、PathMTUDiscoveryBlackHoleについて触れていれば正解となります。
ただし、今回の状況から800というMTU値を推察するのは難しいだろうという事から、サーバのMTU値の設定はどの値にしていても間違いはないものとし、修正箇所と原因に気づければ正解としました。

 

解法

上記で大まかな解説は行っていますが、詳しい解き方については以下をご参照ください。

問題文からヒントを探す

この問題では、「一部見れないページがある」という現象が発生していました。
しかし、そのままではMTUが原因だとなかなか見つけられないかと思います。
なので、「AWS」や「古いネットワーク機材を使っている」というワードを文面に盛り込む事で、環境の違いを強調していました。
この文面から、環境によって引き起こされているトラブルではないか?と考えると解きやすかったかもしれません。

 

手元にある情報から探す

では、本当にページが見れないのか実行してみましょう。
(ブラウザでも確認はできますが、今回はcurlで実行してみました)

# curl -v http://hogehoge/
* About to connect() to hogehoge port 80 (#0)
*      Trying hogehoge ... connected
* Connected to hogehoge ( hogehoge ) port 80 (#0)
> GET / HTTP/1.1
> User-Agent : curl/~~~
> Host :  ipaddress
> Accept :  */*
>

上の結果から、コネクションは張れるけれどページが見れないという状態を確認できます。
また、この時のパケットをwireshark等で確認すると、3WAYHandshake時にMSSで9001という値が交換されています。
(これはWebServerへsshしifconfigする事でもわかります。)
そして、ssh時に帰ってきているパケットを見ると

「ネクストホップのmtuは800だよ」

というicmpパケット(PathMTUDiscovery)が来ているため経路上のMTU値も判断できるのです。
ここまで来ると、なんだかMTU怪しいなと感じませんか?

 

原因を特定する

さて、経路上のMTU値が低い事がわかりましたが、果たしてそれが原因なのでしょうか?
それを特定するためにはFWのコンフィグを見る必要があります。
FWには以下のような設定が入っていました。

・firewallをeth0にセット
・デフォルトアクションはドロップ
・許可するポート番号は80番と22番

つまり、HTTP(80/tcp)とssh(22/tcp)以外は通過できない状態にあったのです。
では整理も兼ねて、現状分かっている情報でトポロジ図を作ってみましょう。

このようになりますね。
それでは、これによってどのような事が起きるのでしょうか?
名前から先にお伝えすると、PathMTUDiscoveryBlackholeという現象が起きています。

PathMTUDiscoveryBlackholeとは・・・
経路上に異なるMTU値が存在していても、 Path MTU Discovery によって通信することができるようになりますが、適正なMTU値を伝達するためのICMP(type3 code4)パケットを送信元に送信しない設定や、途中の経路でICMPがフィルタリングされている場合には、以下のような問題が発生します。以下のような状態の事をPath MTU Discovery Black Holeといいます。

詳しくは以下のリンクへ
引用元 : http://www.infraexpert.com/info/5.2adsl.htm – ネットワークエンジニアとして

 

では以上の事を踏まえ、Webページを参照しようとした場合の流れを考えていきましょう。

Webページを参照する時の流れ

1.ユーザがWebページをサーバにリクエスト
2.3WAYHandshake時に交換したMSSに合わせてサーバがWebページを送信
3.通信経路上にあるネットワーク機器のMTU値が低いため、Webページを受け取れない
4.通信経路上のネットワーク機器(MTU800)がPathMTUDiscoveryをサーバに向かって送信する
5.FWによってPathMTUDiscoveryが拒否される
6.PathMTUDiscoveryBlackholeが発生し、Webページが読み込まれない

通信の流れを文章で書くと、このような形になっていたわけですね。
つまりここを解決できればなんとかなりそうですね!

対処する

そうなると、対処方法としては以下の二つが挙げられます。

・FWでicmpを通すように設定変更を行う (PathMTUDiscoveryのみ許可する場合はtype3code4のみ指定)
・サーバ側のMTUを経路上の最小MTU値に合わせる

このどっちかを行えば、今回の現象を回避できそうです。
ただし、問題文には以下のような記述があります。

尚、変更するのはサーバのみでお願い致します。

ということは、今回はサーバ側のMTUを変更すればよさそうですね。
それではサーバのMTU値ですが

今回の環境だと、このファイルに追加記述する事で変更できます。
追加する内容は以下になります。

これで保存した後に、インタフェースをアップし治す事でMTU値が反映されます。

以上で、対応完了となります。

尚、以上のMTU設定に加え、PathMTUDiscoveryBlackholeについて触れていると完答となっていました。

 

 

まとめ

「PathMTUDiscovery問題」如何だったでしょうか?
序盤の方では「よく見る事」と「気づき」が重要になっていたので、難しい問題になったかもしれません。
そもそもこの問題自体、問題作成や検証にものすごく時間がかかった問題なので、私自体苦労して作っていました。
「MTUは暗黒大陸」なんて言われる事もあるようなので、この問題を通じてMTUの重要さとめんどくささが伝わればと思います!

hardware, コラム, 失敗談, 歴史, 雑談

注意: 読んでも時間の無駄、思い出話です。35歳未満の方はそっと閉じていただければ幸いです。

15年前 「まぁまぁ」定番のNIC

 10年、いや15年以上前の Linux。コンピュータ屋さん以外にもやっと Linux というものが認知されはじめ、流行のディストリビューションは Slackware から Red Hat Linux へ。「どうやら最近の Linux は結構ちゃんと動くらしいね」という巷での噂 …そんな頃を思い出すモノが会社の廃棄物置き場で発見され、思わず救出しました。

dec21140
DEC 21140

 もしかしてこれは DMM が東京進出した際にはじめて導入されたサーバに入っていたNICかも…?

 これは DEC の 21140 というチップが載った 100BASE-TX の NIC です。tulip というコード名のほうが通りがよいでしょうか。当時 Linux での NIC といえば、カニ(Realtek RTL8139シリーズ), 3com 3c905シリーズ、Intel PRO/100(8255x), そしてこの DEC の 2114x 系列 (tulip/de4x5) がポピュラーでした。他にもあることにはありましたが、Linux においての選択肢は多くありませんでした。

  1. Intel eepro100, 3com 3c905: 高級、ちゃんと動く
  2. DEC 21140: そんなに高価じゃない(6,000円程度と記憶) まあまあちゃんと動く
  3. RTL8139C or lator: 安価(2,000円?), やたらCPUを食う、運が悪いとNICが止まってOS再起動、カーネル刺さる
  4. それ以外: 安価、動くかわからない、カーネル刺さる

 この中で “まぁまぁ” の NIC は DEC 21140, これが定番でした。

安いNICはよくカーネルがpanicした

 安いNICはろくなことがありませんでした。CPUを食う、kernel panic で死ぬのは高負荷時とも限らず再現性が謎、速度が超遅くなる、NICの存在ごと沈黙、たまたま動いていてもカーネルをアップデートするとおかしくなるなどなど。珍しいパターンでは ネットワークに何かしら流れていないとCPUが食われてしまう(トラフィックのグラフと CPU使用率のグラフが対称っぽい形を描く)、などなど、さまざまな珍現象に見舞われました。

 FreeBSDの rl, RTL8139 ドライバのソースに「史上最低のひどいチップだ」のようなコメントが書かれていたことも話題になりました。

dec21140_2
DEC 21140 裏 (ぷらっとホーム)

 なんと、ぷらっとホームのシールが貼られています。DMM が東京進出した際のサーバがぷらっとホームの3Uのものだと聞き及んでおりますので、それに入っていた NIC でしょうか。

 tulip 互換をうたうチップはいくつか存在し(NETGEAR, ADMtek, なんかがあったような), ドライバのソースは互換チップのバグ ワークアラウンドで肥大化していた記憶があります。でも互換チップもちゃんと動かなかったような…

 この頃の PC-UNIX はメジャーな製品(≒ブランド品)しか動かず、貧乏学生のお財布には厳しかったものです。今日 2016 年 では Linux でもだいたいドライバはあるし、カーネルを巻き込んで死ぬようなものはとても少なくなりました。仮想化もあるし。何かハードウェアを買おうとする前に、Linux で動くのかどうか調べまくる人も減ったでしょう。


 ――なんて話を同年代の方々にしたら「チューリップ? そんなのあったなー」「俺は BSD だったし 21140 に特に思いdeはない」など しょっぱい反応……。そんな方々にも以下のカードはお気に召していただけたようです。

adaptec AHA-2940U2W
adaptec AHA-2940U2W

写真を撮ったあとそっと廃棄物置き場へ戻しました…。Interop 2016 でインターネットの未来を見たあと、ちょっと昔の思い出に耽っていました。
「歴史って、人類や生命全体の “おもいで” に違いないのよ」

PAGE TOP