Hogyan nem találtam hibát a TSharkban

Miután két napon keresztül bohóckodtam egy AWK szkripttel, ami TShark által lesniffelt, majd a TShark prokoll dekóderén áthajtott adatokat dolgoz fel, és capture file-ból már hibátlanul működött mind a TShark-os dekódolós rész, mint az AWK szkript, gondoltam ideje kipróbálni valódi környezetben is dolgot. Felkerült egy tesztrendszerre, pár módosítás a capture-t végző szkriptben, hogy valódi sniffelés legyen, ne capture fájlból olvasson, aztán mindenkit odacsődítettem, hogy na, ezt nézzétek, elkészült, és... kopp. Nem megy. Á... igen, rövid hegesztgetés a capture filteren, apróbb állítgatás a protokoll dekóderen, na, majd most... kopp. Még egy kis mókolgatás, és... kopp, kopp, kopp.

Egy jó másfél órás túrás után kiderült, hogy a szkript lelkének számító "tshark ... | magic.awk > /dev/tcp/1.1.1.1/1111" szerkezetű sorban (a /dev/tcp/IP/port Bash specifikus) már a legelején elkerülik a pipe-ot az adatok. Persze én a másik végéről visszafelé haladva ellenőriztem mindent, ez nem is kérdés. A probléma egyébként roppant egyszerű: capture filter használata esetén az STDOUT-ra nem ad semmit a TShark, ami nem valami szép dolog tőle. Az alábbi egyszerű példák megvilágítják, hogy mi is a gond. Tegyük fel, hogy folyamatos ICMP forgalmunk van a 192.168.0.1 és a 192.168.0.2 között.

Capture filter és pipe nélkül minden rendben:

betazed:~# tshark -i eth2
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.000000 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.000118  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filterrel, de pipe nélkül is OK:

betazed:~# tshark -i eth2 icmp
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.000000 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.000103  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filter nékül, pipe-pal:

betazed:~# tshark -i eth2 | grep .
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
  0.541318 192.168.0.1 -> 192.168.0.2  ICMP Echo (ping) request
  0.541418  192.168.0.2 -> 192.168.0.1 ICMP Echo (ping) reply
  ...

Capture filterrel és pipe-pal:

betazed:~# tshark -i eth2 icmp | grep .
Running as user "root" and group "root". This could be dangerous.
Capturing on eth2
^C26 packets captured

Az STDERR-re kikerül a CTRL+C megnyomása után, hogy 26 csomagot fogott a TShark. Szép, szép, de hová tette azt a 26 csomagot? A grep tutira nem nyeli le őket, hiszen ebben a formában mindent átenged, ergo meg sem kapja az STDIN-jén az adatokat. Akkor vajon mi lehet gond? Rövid töprengés után (vö. Gyalog galopp boszorkányégetős jelenet) megvan az itélet: biztosan a TShark vacak, máglyára vele. Nincs is szebb annál, mint amikor a hülyeség szorgalommal párosul, lejelentettem hibára a bugs.wireshark.org-on. Nem tudom, hogy a véletlenül kapott mágikus erejű bug ID (7777) hatására, vagy azért, mert egyébként is jól felépített szervezetet tolt a Riverbed a Wireshark alá, de húsz perc múlva volt megoldás: user error. Khm... nos, igen, körülbelül iyen "Operációs rendszerek" szeminárium első évfolyam, első félév, második alkalom szintű dologról van szó, nem tudtam, hogy az STDOUT pufferelt, és ha nincs elég sok adat a TShark kimeneten, akkor bizony sokáig a pufferben ragadnak a dolgok. Ezért abban az esetben, ha TShark van a pipe elején, "-l" kapcsolóval érdemes elindítani, akkor azonnal ürül a puffer minden egyes csomag feldolgozása után. Innen persze már működött a csoda szkriptem is, az más kérdés, hogy a végső változatban mégsem TShark-kal sniffeltem, hanem ngrep-pel, és a TShark parancssori protokoll dekódere helyett mindent AWK-val oldottam meg, nem is ez a fontos, hanem az, hogy a szakmában töltött évek száma semmilyen kapcsolatban nincs az ember valós vagy inkább vélt tévedhetetlenségével.