Ja, ich weiß, Paket-Sniffer sind böse Hackertools und so weiter – wer das Denkt sollte hier aufhören zu lesen und erst eine Prise Praxis zu sich nehmen. Gerade wenn es um das Debuggen von Fehlern in Netzwerkverbindungen geht kommt man nur schwer dran vorbei – wenn man nicht gerade zwischen den Geräten sitzt wird es jedoch schnell ungemütlich. Gehen wir fon folgender Konstellation aus, welche bei mir derzeit aufgetreten ist: Ein Mobilgerät kommuniziert mit einer Webbasierten API über HTTP – der Server steht nicht unter meiner Kontrolle und das Mobilgerät ist selbstverfreilich entsprechend vernagelt. Natürlich könnte man nun einen Monitoring-Port an einem Switch zwischen Mobilgerät und Internetzugang nutzen, aber der liegt weit entfernt und ich müsste zwischen zwei Orten pendeln.

Bisher hieß das für nicht: 2-Schritt-Debugging. Erst verband ich mich auf den (Linux-basierten) Router, fertigte mit tcpdump ein Capture-File an und lud es auf den PC um in Wireshark einen Blick in die Pakete zu werfen. Dank eines Hinweises auf einen Artikel bei Commandlinefu kann ich mir das nun sparen – dank Pipes und ssh lassen sich tcpdump und Wireshark so verschalten, dass ein Live-Capture des Remote-Servers im lokalen Wireshark einläuft. Macht das Ganze wesentlich einfacher…

Ein möglicher Befehl wäre z.B.

ssh root@internetrouter tcpdump -i eth0 -U -s0 -w - 'port 80 and host 192.168.1.2'  | wireshark -k -i -

der letzte Teil des SSH-Commands entspricht den üblichen tcpdump-Filtern – hier sollte man auf jeden Fall drauf achten, dass man den ssh-Traffic nicht mitschneidet – in diesem Fall ists durch die Host/Port-Einschränkung ja ohnehin gegeben, ansonsten sollte ein ’not port ssh‘ helfen.