雪だー！
まあ歩きで会社行けるし、もう雨になってるんであんまり関係ないんですけどね。 と思って外出たら、むしろめっちゃ冷たい風がめっちゃ強く吹きつけてくるもんで、想像以上にしんどかった。油断したわ。
なかなか上手くいかんなぁ。 以前の修正で、一部は上手くいったようだがまだ駄目でした報告が上がってくる。
ログを取ってもらうと、どうもSSDPの探索後にサービスの情報を取りに行って上手く取得できてないのかな？ よく見たらエラー処理全くしてないので、とりあえずエラーをトラップしてログ出力してみるようにして確認をお願いした。 すると、変なアドレスにアクセスしようとして失敗してるようだ。 どうもデバイスの詳細アドレスじゃない物が混じってくるっぽい。 ていうかUPnPのデバイスじゃない物がSSDPに混じってくる。これは無視できるようにしないとなー。 まあエラー処理さえちゃんとしておけばいいや。 エラー処理がちゃんとできておらず、一つ失敗したらそれ以降の処理が他のデバイスも含め全て行われないようになっていたので、 デバイス詳細取得に失敗したらそいつは無視するようにして他のデバイスをちゃんと扱うようにした。
これでいったかと思ったらまだだめー。 なんかエラーが返ってきてるぽいけど、そもそもエラー情報がちゃんと取れてない。なんでだ。
返ってきてるものをそのまま表示するようにして試してもらうと、UPnPErrorに名前空間がついてる。あれ、これついてるんだっけ。 errorCodeとかerrorDescriptionは名前空間に入ってるのにその指定がされてないので取得できなかったようだ。 でもここってコード上はわざわざ空の名前空間指定してるから空じゃないとだめじゃない？と思ったが、空なのはActionの引数とか返事のパラメータで、それと混同しちゃったようだ。できたできた。
さて中身を見ると以前も貰った-111でInvalid Actionのエラーだ。なんだろうこれ。 なんだかは分からんがMono.Natでは動いてたというので俺のコードが悪いだけで上手く書けば動きはするんだろうな。 引数の順番かと思ったがGetExternalIPAddressは引数無いので順番も何もない。 リクエスト部分がなんか怪しいな。
と、調べていると、-111ていうエラーがlibupnpのヘッダにあることを教えてもらった。UPNP_E_INVALID_SERVICEだそうな。 丁度リクエストの辺りのドキュメントを良く見てたところ、アクション実行のHTTPリクエストに設定するSOAPACTIONヘッダの値は二重引用符で括らないといけなさそうなのにやってないことに気付いた。 エラー名としても合ってそうなのでこれっぽいな。 これ無くても多くのデバイスで動いてしまうので見落としてたのか。 しかし括る必要性がわからないんだがなんで必要なんだろな。
修正して試してもらったところ無事動いた模様。 ちょっと遅いのが気になるところではあるが、それはあとで直すとして、まあ動きはしたのでとりあえずはOKでしょう。 やっとUPnP対応も上手くいったかなー？
しかしすぐにいろいろ試してくれる人が居て本当に助かった。 持ってないデバイスに対応するのはやっぱり難しいなぁ。 仕様書しっかり読んできっちり対応すればいいんだけど、手元で動いちゃうとね……。