タグ別アーカイブ: network

[Linux] ping された事を検知する(tcpdump)


ネットワーク到達確認をするときにpingをうちますが、
自分が本当にpingを受け取ったのか確認したい事もたまにあります。

こんな時、pingされたことを検知するには、tcpdumpを使うと便利です。

> sudo tcpdump ‘icmp[0] = 8’

############ 監視サーバ側 ############## 
% sudo tcpdump 'icmp[0] = 8'     
[sudo] password for user: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
(監視状態に入る)

ここで監視サーバにpingが来ると監視サーバには以下のようにログが流れます。

17:35:23.241574 IP xxx.xxx.xxx.xxx > example.com: ICMP echo request, id 13727, seq 0, length 64
17:35:24.241852 IP xxx.xxx.xxx.xxx > example.com: ICMP echo request, id 13727, seq 1, length 64

xxx.xxx.xxx.xxxは実際にはping元のIPアドレス(またはホスト)、example.comはping先(監視サーバ)のIPアドレス(またはホスト)になります。

終了するときは Ctrl-C で終了します。

Mac OS X でポートを開いているプログラムを調べる


WindowsやLinuxでは netstat の -bオプションや-pオプションでポートを待ち受けているプロセスを調べる事ができるのに、Mac OS Xではそんなオプションが無く困った。

なんとか方法が他にないか調べた所、
Mac OS X では lsof を使うのが一番簡単そう。

$ lsof -i | grep LISTEN

結果はこんな感じになる。

$ lsof -i | grep LISTEN
Dropbox     303   user   19u  IPv4 0xffffff0123456789      0t0  TCP *:17500 (LISTEN)
Dropbox     303   user   25u  IPv4 0xffffff0123456789      0t0  TCP localhost:26165 (LISTEN)
node      56728   user    8u  IPv4 0xffffff0123456789      0t0  TCP *:hbci (LISTEN)
mongod    57071   user    6u  IPv4 0xffffff0123456789      0t0  TCP localhost:28017 (LISTEN)
mongod    57071   user    7u  IPv4 0xffffff0123456789      0t0  TCP localhost:27017 (LISTEN)

調べようと思った動機は mongodb のListenポートをど忘れして確認したかっただけでした。
実行結果を見ると mongodb は TCP localhost:27017, TCP localhost:28017とあるので、
待ち受けているポートはTCPポート27017, 28017の2つですね。

Android – HttpClient のクッキー管理機能をカスタマイズする


HttpClient のクッキー処理の仕様をブラウザに合わせたい、RFC準拠にしたい、自分で管理したい、という時はクッキーポリシーの設定で動作を変更することができます。
方法1: 標準で提供されているクッキーポリシーを選んで設定する
例:

DefaultHttpClient client = new DefaultHttpClient(params);
client.getParams().setParameter(ClientPNames.COOKIE_POLICY, CookiePolicy.NETSCAPE); // SetCookieの扱いをNetscapeの仕様に変更

 
設定可能な値:
– CookiePolicy.BEST_MATCH … デフォルトのベストマッチポリシー
– CookiePolicy.RFC_2109 … RFC2109に準拠(時代遅れの厳密なポリシー)
– CookiePolicy.RFC_2965 … RFC2965に準拠(標準的で厳密なポリシー)
– CookiePolicy.NETSCAPE … ネットスケープのドラフトに準拠
– CookiePolicy.BROWSER_COMPATIBILITY … (おかしな)一般的なブラウザと互換性がある動作にする。
 
方法2:カスタムポリシーを使う
例:

DefaultHttpClient client = new DefaultHttpClient(params);
// カスタムクッキーポリシーを定義する
CookieSpecFactory csf = new CookieSpecFactory() {
 
@Override
public CookieSpec newInstance(HttpParams params) {
return new BrowserCompatSpec(){
@Override
public void validate(Cookie cookie, CookieOrigin origin)
throws MalformedCookieException {
// ここで判定してクッキー導入処理を行う。
// super.validate(cookie, origin);
}
};
}
};
client.getCookieSpecs().register(“myspec”, csf); // カスタムポリシーに結びつけるキーワードを登録して・・
client.getParams().setParameter(
ClientPNames.COOKIE_POLICY, “myspec”); // そのキーワードでポリシーを設定!

 
カスタムポリシーを定義する場合は標準で提供されているポリシーのソースが参考になります。
 
– RFC_2109 … RFC2109Spec.java
– RFC_2965 … RFC2965Spec.java
– NETSCAPE .. NetscapeDraftSpec.java
– BROWSER_COMPATIBLE .. CookieSpecBase.java
 
その他クッキー関係の設定方法は公式ドキュメントに詳しく書かれています。
 
参考:
HttpClientでのCookieの扱い(HttpClient3.0-rc3)
HttpComponentsライブラリ公式ドキュメント(hc.apache.org)
RFC2109(日本語訳)
RFC2965(日本語訳)
HttpComponentsのcookieパッケージソース(svn.apache.org)

HTTP – Locationヘッダには相対URLを使ってはいけない


HTTP の仕様(RFC2616)では、 Location ヘッダは絶対URIでなければならないと今更知りました。
Hypertext Transfer Protocol — HTTP/1.1(日本語) 14.30:

Location = “Location” “:” absoluteURI

ちなみに絶対URI(absolute URI)とはRFC2396によるとスキームから始まるURIのみを指します。
スラッシュ(“/”)から始まる URL が絶対URLと言われることがありますが、正確には絶対パス(absolute path)指定の相対URLであり、絶対URLではありません。

absoluteURI = scheme “:” ( hier_part | opaque_part )
hier_part = ( net_path | abs_path ) [ “?” query ]
relativeURI = ( net_path | abs_path | rel_path ) [ “?” query ]
net_path = “//” authority [ abs_path ]
abs_path = “/” path_segments

 
ただ、ほとんどのブラウザで相対URLへのロケーションを寛容に解釈してくれます。
lynx では警告が出るようですが、一般向けには携帯でさえ(mova など余程古いものを除けば)意図通りにリダイレクトしてくれるようになり、仕様違いでも問題がほぼなくなってしまいました。
 
相対URLが便利なのも事実。なのでもしかしたら HTTP 2.0 ができるときには相対URI可、なんてことになるかもしれませんね。

インターネットにつながずに2台のマシンを無線通信する


無線LANでピアツーピア接続(アドホックモード)する方法(東芝 dynabook サポート)
XP/Vista なら標準でアドホック(P2P)接続できるのですね。
 
参考:
無線 LAN を使いこなしてトクする Windows XP – パソコン同士でつなぐ(Microsoft At Home マガジン)
 
WiPeer
XP/Vista 用のP2Pメッセンジャー。ファイル共有機能つきで、通信の暗号化アルゴリズムはWEPのみ。
 
アドホックで無線通信を可能にする『WiPeer』

任意のデータを表現するURL


RFC 2397 に規定される data:// から始まる URL を利用すると、任意のデータを URL として表現できます。

書式:
“data://” [MIME] [“;base64”] “,” data

たとえば

<a href=”http://www.ecoop.net/”>hello!</a>

という HTML テキストは data スキームを使うと以下のようになります。

data://text/html,%3Ca+href%3D%22http%3A%2F%2Fwww.ecoop.net%2F%22%3Ehello%21%3C%2Fa%3

また、base64 形式でも指定できます。

data://text/html;base64,PGEgaHJlZj0iaHR0cDovL3d3dy5lY29vcC5uZXQvIj5oZWxsbyE8L2E+

 
IMG タグのソースURLとして利用する例(RFC2397より引用)

   <IMG
   SRC=”data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
   AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
   ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
   a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
   ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
   F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
   hhx4dbgYKAAA7″
   ALT=”Larry”>

テキストファイルだけでなく画像データや音声データなど、任意のデータファイルを表現することができます。ただし A タグのHREF属性で利用する場合など利用環境によって URIの文字列長制限がある場合もあるため、比較的小さいデータを表現するときに利用するのがいいでしょう。
 
参考:
RFC 2397 The “data” URL scheme

UDP Hole Punching の実験


以前から気になっていた、NAT ごしに UDP 通信を行う, UDP Hole Punching の実験を NetCat(ports: net/netcat) を使って行ってみました。
 
1. (A)ホスト側端末(Firewall なし), WAN IP アドレス: 10.0.1.2

nc -lup 1234 -v # UDP の 1234 番で LISTEN

 
2. (B)クライアント側端末(ルータあり), 端末の IP アドレス: 192.168.1.100, ルータの WAN IP アドレス: 10.0.5.6

nc -u -p 5678 10.0.1.2 1234 # 10.0.1.2 の UDP 1234 に接続

 
3. (B) で Hello を入力
 
4. (A) に以下のようなログが出る

connect to [10.0.1.2] from ********* [10.0.5.6] 50000
Hello

(この例では 10.0.5.6 の UDP50000ポートからの送信があった。クライアント側 NAT で送信元ポートが書きかわっている事に注意)
 
5. (A), (B) 両方で netcat を一度終了させる
 
6. (B) で, 先程送信元にしたポートに対して UDP 受信を開始する(src port, dst port の入れ換え)

nc -lup 5678 -v

 
7. (A) で, 先程 LISTEN していたポートから、(4) で送信元になっていた IP アドレス、ポートに対して接続を開始する

nc -u -p 1234 10.0.5.6 50000

 
8. (A) から Hello over NAT を送信
 
9. (B) で以下のようなログが表示される

connect to [192.168.1.100] from ********* [10.0.1.2] 1234
Hello over NAT

 
両方が NAT 内にいる場合、双方について source port が書きかわるため、(A),(B) が通信することが不可能になります。
この場合、双方の source port を記録するための非 NAT 内ホスト端末 (C) が必要です。
ただし、双方が Symmetric NAT 内にいる場合は、宛先のポート番号に対して送信元の IP アドレス、ポート番号が固定されるためこの方法を用いることができません。
 
参考:
P2Pとファイアウォール
ごろ猫ブログ
みかログ
IT media エンタープライズ:PART2 Skype, その通信の仕組み

bind で設定が反映されない場合の原因と対策


– named.conf の場所が違う, または権限が不足している
  named の起動オプションで

named -c /etc/named/named.conf

   のように -c で設定ファイルへのパスを指定してみましょう。
 
– 名前解決で自分を見ていない
  > nslookup example.com 127.0.0.1
  または
  > dig @127.0.0.1 example.com
  でDNSサーバを明示してみます。
  これで解決できるなら、解決先が正しくない可能性が高いです。
  たとえば UNIX 系なら /etc/resolv.conf で
  > nameserver 127.0.0.1
  のように解決先を指定していない可能性があります。
 
– 設定ファイルの文法が間違っている
  文法が間違っていると、黙ってその設定ファイルを無視します。
named.conf と zone ファイルの文法を次のコマンドでチェックしてみましょう。

named-checkconf <named.conf のパス>
named-checkzone <ゾーン名> <ゾーンファイルのパス>

 
具体的にはたとえば次のようにします。

named-checkconf /etc/named/named.conf
named-checkzone example.com /etc/named/example.com.zone

これを実行し、named-checkconf の場合何も表示されなければ、named-checkzone の場合最後に OK と出れば、そのファイルの文法は正しいということです。
 
文法が間違っている場合、エラーメッセージが出力されるので、それを元に正します。
 
– 設定ファイルの変更後、DNS をリロード/再起動していない
  設定ファイルは、リロードまたは再起動しないと即時反映されません。
  > /sbin/named.reload
  などとして、明示的にリロードすることで直ちに反映されます。
 
参考:
@IT:実用 BIND 9 で作る DNS サーバ

Ethereal,Tethereal が FreeBSD の ports から消えてた


ローカルの ports で探してみて、net/ethereal にあったはずの Ethereal が見付からなくてアレッ!?と思って公式の cvsweb をあたって見たところ
次のように書いてました。
 
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ports/net/ethereal/Attic/Makefile?hideattic=0

FILE REMOVED
 
Add wireshark and tshark after repocopies from ethereal and tethereal
respectively. Wireshark is a rename of ethereal after the principal
developer moved companies and lost the Ethereal copyright.
 
Messenger, don’t shoot!
 
Now the ethereal binary is called wireshark, the tethereal binary is
called tshark, and idl2eth is now idl2wrs. All other binaries have
kept the same name.
 
In addition to this name change, I have also changed the PREFIX from X11BASE
to LOCALBASE.

 
Ethereal(CUI 版: TEthereal) は主要な開発者が会社を辞めて商標権を失って wireshark(CUI 版: tshark) という別の名前で存続する事になった、ということです。
 
ということで ports を改めて見ると、 net/wireshark, net/wireshark-lite, net/tshark, net/tshark-lite が増えてました。
 
Wireshark の公式サイトは http://wireshark.org/ で、
現在、Ethereal 0.99 から更新された Wireshark 0.99.2 がリリースされています。
 
参考:
「Ethereal」は「Wireshark」に飲み込まれるのか?(ITpro)
Wireshark 公式サイト
Ethereal 公式サイト

Ethereal – TCP の生のデータを保存する


Follow TCP Stream を使えば生の TCP ストリームデータを取得可能です。
 
例えば、HTTP で画像を取得して、その画像をファイルとして保存したい場合は
次のようにします。
 
1. HTTP/1.1 200 OK などの HTTP レスポンスパケットを選んで右クリック→Follow TCP Stream を選択
2. Follow TCP stream ウィンドウが開いたら、右下の Raw をチェック
3. Save As をボタンをクリック
4. 保存先を指定して保存(保存例: http_gif.dat|rs/http_gif.dat)
5. バイナリエディタを開き、0D 0A 0D 0A 以前(HTTP Header)を削除し、拡張子変更(変更例: 画像)
 
追記:
(2006-07-27)同日の別トピックに書きましたが、Ethereal は複製版が Wireshark として独立し、そちらが更新されています。