[samba-jp:22018] Re: OS X Mavericksのファイル共有はSMB2が優先

HAT hat @ fa2.so-net.ne.jp
2013年 6月 13日 (木) 22:10:11 JST


HATです。

>> 現行OS X 10.8から色々なSMBサーバに接続してファイル内容の検索、
>> 具体的にいうとテキストファイル内のASCII文字列を検索してみると、次のような
>> 結果になります。
>> 
>> OS X 10.8 から OS X 10.8      にSMB接続 ○
>> OS X 10.8 から Windows 7 Home にSMB接続 ×
>> OS X 10.8 から Samba 4.0.6    にSMB接続 ×
>> 
>> なぜOSX-OSXのときだけ検索に成功するのか。
>> この状態だけWindows Search Protocolが使われているのか。
>> 今度パケットダンプして調べてみます。

OS X 10.8とOS X 10.8をAFP及びSMBで接続し、"uname"という文字列を検索させ、
リクエストが発生したときのパケットをダンプしてみました。
Fedora 18上でstoneを実行して、SMB及びAFPを中継して、Fedora 18上の
wiresharkにてダンプしました、

つまり、
  OSX10.8 machineA ---(AFP)---> Fedora/stone ---(AFP)---> OSX10.8 machineB
  OSX10.8 machineA ---(SMB)---> Fedora/stone ---(SMB)---> OSX10.8 machineB
です。
こういう手法なので、src側のMACアドレスはAppleですが、dst側のMACアドレスは
ロジテックになっています。うちのショボいサーバ環境がバレバレです。

AFPにて検索したときのダンプ結果が、添付ファイルafp_search.pcapngです。
これは、AFPのFPSpotlightという命令です。
FPSpotlightは仕様が非公開ですが、Netatalk開発者がhackに成功しており、
次期Netatalk 3.1にて実装予定です。

SMBにて検索したときのダンプ結果が、添付ファイルsmb_search.pcapngです。
パケットの内容を見ると、上記AFPの場合と酷似しています。
AFPと同じ命令をそのままSMB上に流しているように見えます。

AFPの非公開コマンドがSMBにて定義されているでしょうか。
AppleがSMBを勝手に拡張していると考えてよいのではないでしょうか。

-- 
HAT
-------------- next part --------------




t
-------------- next part --------------




t


samba-jp メーリングリストの案内