プログラマー探偵の事件簿：wifiとLANポートの落とし穴

プログラムが動かない原因がプログラムとは関係ないところにあることに度々遭遇する。今回はネットワークの問題で起こった不思議な現象の話。助手の猫に、この問題を早く調査しろと今朝３時に起こされたが眠くて５時まで二度寝した。猫は３時と５時に、ご飯を食べて満足して寝ている。

問題の始まり

Raspberry PiでSNMPエージェントを動かす実験

をした後、ついでなのでGO言語で作ったSNMPエージェント

をRaspberry Piで動かそうとした。テストプログラムを快調にビルドして起動できた。Raspberry Pi上でのテストもOK。後はTWSNMPからMIBを取得して完了と思ったが、

のエラーがでた。他のエージェントへのアクセスはまったく問題ない。今回作ったGO言語のエージェントの問題なのか？

別の取得方法を試す

TWSNMPの問題なのかGO言語のSNMPエージェントの問題なのか切り分けるためにまずは、TWSNMP以外でMIBを取得してみる。Mac　OSにもNet-SNMPが入っているので試すと

% snmpwalk -v 2c -c public 192.168.1.26 system
SNMPv2-MIB::sysDescr.0 = STRING: test
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-MIB::sysDescr.0
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (334) 0:00:03.34
SNMPv2-MIB::sysContact.0 = STRING: test sysContact
SNMPv2-MIB::sysName.0 = STRING: test sysName
SNMPv2-MIB::sysLocation.0 = STRING: test sysLocation
SNMPv2-MIB::sysServices.0 = INTEGER: 72
End of MIB

問題ない。TWSNMPの問題か？でも、他のSNMPエージェントへのアクセスは問題ない？　まったく不思議な現象である。

天下の宝刀パケットキャプチャー

通信プログラムの問題を調べるにはパケットキャプチャーが役に立つことが多い。パケットキャプチャーするために

Wireshark · Download

をインストールした。

うまくいく場合（Net-snmp)とだめな場合（TWSNMP）があるので両方の通信を比較してみれば何かわかるかもしれない。

緑の枠のOKな場合と赤の枠のNGな場合は一見何の問題もないように見える。最初のリクエストに違いはない。NGな場合は、応答が受信できないのでもう一度リクエストを送信している。結果、画面に表示されたエラーメッセージのTimeoutと一致している。GO言語のSNMPエージェントが応答を返しているのに何故だ！謎は深まる。

「パケットをよく見ろ！」と助手の猫

「よく見てる」と言い返すも、もう一度よくみて見る。あ！

リクエストを送った宛先のIPアドレスと応答を返した送信元のIPアドレスが違う！これだ！！！

問題の真相

まず、Raspberry Piは、LANポートをWifiの２つでネットワークに接続している。Wifiは最初に設定していが、LANポートは、

の実験の時にDHCPで自動的に有効になった。

Wifiのアドレスが192.168.1.26,LANポートが192.168.1.18である。
つまり、Wifiのアドレスに送ったリクエストにLANポートから応答しているのである。Net-SNMPのsnmpwalkコマンドでは応答の送信元のIPアドレスに関係なく応答を受信できるがTWSNMPで使っているGoSNMPパッケージはリクエストを送信した宛先のIPアドレスから応答がないとパケットを破棄するようになっている。これが今回の謎の原因であった。

リクエストを送信するIPアドレスをRaspberry PiのLANポートのアドレスに変えて解決した。

この謎の現象に振り回されて危なくプログラムのソースコードをあてもなく彷徨う迷宮に踏み込むところだった。