[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 メーリングリストの案内