引越し屋さんは手際がよかった。

速度がでない感じのフレッツ光だけど、前言った実運用構成にしたら、最大 70M ぐらいまで出るようになった (Radish 東京)。そしてなぜかこの状態でフレッツスクエアの速度測定をすると 3M ぐらいしかでない。別にいいけど謎い。

でも実際、早くなってもそんなに実感はない感じ。セットアップファイル落とすときぐらいだ。

  1. トップ
  2. life
  3. 引越し
  1. トップ
  2. net
  3. 引越し

svn の HEAD を自動で公開したい。Apache さんが HEAD を普通のファイルとして認識して、普通にアクセスできる感じ。既存のものをそのままバージョン管理するような。

想定:リポジトリと Apache は同じマシンにある。

とりあえず、svn の fsfs がどっかにまとめて HEAD をもっているなら、それに symlink すれば解決だなぁと思ったのだけれど、fsfs は最初からの差分しかもっていないらしい (db/revs/{?d+})。さてどうしよう。

  • コミットをフックして (hooks/post-commit?) 公開ディレクトリを自動で svn up
  • libsvn とかでリポジトリの HEAD をどっかにマウントできる fs を作る (fsfs の場合重すぎてやばそう)

CLON - 2006/07/24

おお、なるほど。dav 化して davfs するんだ。

  1. トップ
  2. svn
  3. svn fsfs, svnfs

やっぱ、PPPoE で繋ぐ先ってどうやって決定されるんだろう、と疑問だったので調べた。

PPPoE は PPP フレームをイーサーネットフレームでカプセル化することにより動作する。このプロトコルには、発見とセッションという 2 つの異なるステージがある。

発見ステージでは、ホストはアクセス集信装置を発見するために特別な PADI (PPPoE Active Discovery Initiation) フレームをブロードキャストする。 (一般的には、ただ 1 つの) アクセス集信装置が PADO (PPPoE Active Discovery Offer) パケットを返し、集信装置が存在することとサービスを提供することを知らせる。ホストはアクセス集信装置を 1 つ選び、セッションを開いてもらうために PADR (PPPoE Active Discovery Request) パケットを送る。アクセス集信装置は PADS (PPPoE Active Discovery Session-Confirmation) パケットで応答する。この後、プロトコルはセッションステージに移行する。

セッションステージでは、ホストとアクセス集信装置の間でイーサーネットフレームに埋め込まれた PPP フレームがやりとりされる。通常のイーサーネット MTU は 1500 バイトであるが、 PPPoE のオーバーヘッドに加え、カプセル化された PPP フレームによる 2 バイトのオーバーヘッドがあるので、 PPP インターフェースの MTU は最大 1492 バイトになる。 Linux マシンをファイアーウォールとして使用しており、ファイアーウォールの背後にあるインターフェースの MTU が 1492 より大きいと、あらゆる問題が発生しうる。実際、安全のためにファイアーウォールの後ろのマシンの MTU を 1412 に指定しておくことを推奨する。これにより、ヘッダに TCP オプションと IP オプションが入るという最悪の場合も許容できる。

最初はブロードキャストするようだ。

上のことを念頭において RFC2516 を読んでみると、5.1 The PPPoE Active Discovery Initiation (PADI) packet とかいうところから上とほぼ同じ説明 (もっと具体的) がある。


PPPoE ブリッジとは何か? ここを読んでみると、ようはルータが PPPoE フレームをスルーしてくれる?程度のものっぽい。


ひかり電話のセッション情報は起動時に PPPoE + HTTP で落としてくるみたいだけど、その設定ってどこにあるんだろう。NTT がレンタル機器を送るときに MAC アドレスを登録して云々みたいなことをやっているのかな?

  1. トップ
  2. net
  3. PPPoE ってどうやって