思わず、 UPnP を調べることになった (2)

大量の"RST"パケットが打ち出されている状態では、ネットワークにつなぐわけにもいかないので、パケットの送出を停止することを優先して、送出原因を探りました。

原因は、SSDP Discovery Service

結論から述べると、原因は、「SSDP Discovery Service」というサービスの一つでした。 やっぱり、 Micro$oft のしわざか。 「コントロール・パネル」→「管理ツール」→「サービス」で開くウィンドウから開始と停止を指示することができます。

ただし、パケットの送出が始まった状態では、このサービスを停止しても効果がありませんでした。

1. ネットワークに接続せずPCを起動する
2. 「SSDP Discovery Service」サービスを停止する
3. ネットワークに接続する

この手順をとると、この問題に関する"RST"パケットは送出されなくなります。 さらに、この状態から「SSDP Discovery Service」サービスを開始しても"RST"パケットは送出されません。

恒久的な対策として、「SSDP Discovery Service」サービスの「スタートアップの種類」を「手動」から「無効」に切り替えるとうまくいきます。 ただし、ブロードバンドルータを使っている環境では、このサービスを使わないとストリーミングの動画を見ることが出来なくなってしまうようです。 やはり、 KB967751 パッチと関連するみたいだな。

私は、こうして、RSTパケットを止めました

Symantec Firewall の Log を見ただけでは、IPアドレスとポート番号しかわかりません。 また、Wireshark を使っても、通信内容を傍受することはできますが、どのプロセスが発したパケットかを判断することはできません。

そこで、参考サイトにあった方法を使って、プロセスを特定することにしました。 コマンド・プロンプトで "netstat -ano" コマンドを使うと、使用しているプロセス番号と共にコネクション一覧が表示されます。

Active Connections

  Proto  Local Address        Foreign Address        State        PID
  TCP    192.168.XXX.34:5152  192.168.XXX.254:49152  CLOSE_WAIT   1292

このように表示され、PCの5152番ポートとブロードバンド・ルータの49152番ポートにコネクションが張られているのがわかります。 （この例は、イメージです。） コネクションは、一秒ごとに、ごく短時間で解除されるので、すぐには捕まえられないかもしれません。 コマンドを何度か打っていると、そのうちに「当たり」を引くことができます。

ポートを使用しているプロセス番号が 1292 だと判明したので、今度は、このプロセスの正体を突き止めます。 プロセス一覧を表示するには、 "tasklist /svc" というコマンドを使います。

イメージ名                   PID サービス
========================= ====== =============================================
svchost.exe                 1292 AudioSrv, Browser, CryptSvc, Dhcp, ERSvc,
                                 EventSystem, helpsvc, lanmanserver,
                                 lanmanworkstation, Netman, Nla, RasMan,
                                 Schedule, seclogon, SENS, SharedAccess,
                                 ShellHWDetection, srservice, TapiSrv,
                                 Themes, TrkWks, w32time, winmgmt, wscsvc,
                                 wuauserv
svchost.exe                 1628 LmHosts, RemoteRegistry, SSDPSRV, WebClient

すると、プロセス1292は、このように多くのサービスの仕事を押し付けられていることがわかります。 ごくろうさま。 （この例は、イメージです。） これらのサービスを一つずつ止めて、原因を探っていくという手順になります。

今回の場合、直接にパケットを打ち出していたのは1292 番プロセスなのですが、そのきっかけを作ったのは、 1628 番プロセスの"SSDPSRV" でした。 しかも、ネットワーク接続時にサービスを停止していないと効果がないというおまけ付きでした。 こりゃ、手探りで原因を突き止めるのは、大変だ。

次の課題

確かに「SSDP Discovery Service」サービスを停止すると妙な "RST" パケットは送出されなくなりますが、ストリーミングが見られなくなるなどの問題もあるようです。 まずは、 KB967751 パッチを戻して、様子を見てみますか。

参考サイト

netstatでリッスンしているプロセスを特定する

Windowsの場合は、こういうコマンドを使うのだそうです。 Linuxの場合は、え～と、何だっけ？