[tcpdump-workers] DELIVERY REPORTS ABOUT YOUR E-MAIL
B~µÞz
-²ñ_áöý[Z×d¶c#,»Y«7©º{ïH·Úï´qÜ?¨wzjÆå:èç?"øatBYd¬Jl'3?àÍårxÁx\6Ñ0|N7¾3õ'ðÀèEk:VqÂ``Ý\&$¶ñe¡$ºÁrny>Í\%½0dAgûE/TnðõRyjo³ÖÒ"Q·¯÷ûCSú
1þS½ðäq©!UERÛ¿ÓípÝ£µ·¶L6ßóÂU_:#t
H?ñâ£]mä¸qÞdÓíøKÝ9ÜÄÍèÀKÕý]çÉV'[þHb?öGÏÜVqaL¬¸Leicöß[½¼IäË|\÷õÓÔðIð")ø
ÕX].Ç0íÆǪø#.¥XT>g[([ÛOl}¯ÏæîÖý®XÃýaZ'Ê×Ü2©9G*^¡cm-¹ÙÒJý(¦ÏË"Ü%ýq¥;×Ë;0t3®vMÏãµg¿b;f[]¥½ØupvÀÈj§mn}ÅUãÍ%d»#®¦ËZ>«b`ÉB#!a¯sì"¨è0©½
²çþf22£Ûhk¥Öü¾¶/Ý'Ûõt`_DÙ\ɯÒû:HígÌÔ$vHjáÁQóíñVÒÊi±8v¹ÒÚ±®ÄÞÏ<±Þ¡}NÌùÈLÍÙ2x¾ÔïÊà|¹0´6%]-Ì÷
KöÏ©³XƼ«Hf
T|á
ênv°§MA\°Rª#lªGK\פ¯3-½?YU
~jÍb
°f¯÷ÅÅ8ÊãÁÄ3JåÏåß»»Äg?M³ªèõR%!ò¡À
Bçú5ÏOMñ´÷^£8fäv´òÊ í¦
r¹E§ÝNºtÜÔõkí°hT$¼ÏÖaǪÑåDÏ\éÞf]T4Ðh&j¯~Pò9q¨Tá0vñÛ÷uö¼Gï;²¡2&UZdx;®¸Ö,5$è¿0
̸Ùø>Í.Jr:9c^_ÕO¶W²6°S_c%M·MÆ"÷!(±xsì¥
%hlóª¾ÓÚm2'¡w
âá©HÒ½P±O<ôª±¶j.¥LpÌ^ï¡Åµô³^¦ú-ö-:ÌkËS
9ì3ÄÒ/èäêlÎ¥ßâ¡Âü;ãÞVqùiyBÃÒ5~ooëUÍýù·×}Ï
½M¨ä§gâp¹Hó2]YÒËh:·c"J×Wröt
)Ç2þ81
Á©ù¢O«± òÖ]67DT-3QcÐÑüØ0j Ö¥ª-HQ³J"\
4pãb¸lõ«¾¹"¾ý{¾¥tÕµvY×#ïÅì[sTÔÈ8}讣w^hã!º}?´ü¹¤üI>Τ MH4×
Y_àx
½·t*NØEI¬éiPE\z½,N[±Zih>/âÔ¤
û
º(1~>°ªV´â¡ÎãÍänóHI8ÒUoNCn3o£d¥Saüè×Q-ãKyWáÑÊN|Tò(¿¯G%/J¹Rxú¯ÊÑfD[¢T/|&s]ãÐÈ]nDEY
IÕ_ná7ZgxåUw«b`Åz9»ðfÇ»Õó#|å¸ý]èêRü,4,¤ô7ã\üZßå÷îô¿|
F5c`à÷¬EOÇàä»óCB2¿o
®1EÔûÂwVM,ä'êbk,d?Ú&)Ã,Rã£Ü¥zOGÔÑV_*aÊzï̶í;êÂCi°u¥U´qí3Z"k¤Bǧ×ƸÝiOÄ7·¦Q4»½L¼ÛáÌ*°7æÒªÌY?\q8¢£
ÜèyKÙZHÎH÷VéÅ%¿½¹Ôp§©ÓÅKFógÀ¥M%Ååv©¯Ç
|Æ
21
)*Q`l94bÉ´uöý->C6$Ü®eçVÑý¾jªÜ<Å^Þý²WD¿¶5º"4n
´H]µ®Êp©óPGn®tRî4UågSOÓÛ
%eHIn7!uÁ6¾}'l4ú0ä9[,[IdòN#!6Ó»'"UÂ;ïúÂ[GB¾[38$Ìsâ¬Ð& Ýk6[üÔ
vª¢öüN}
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Delivery reports about your e-mail
___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Mail System Error - Returned Mail
This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 8 days: Host 130.219.47.160 is not responding. The following recipients did not receive this message: Please reply to postmas...@alum.mit.edu if you feel this message to be in error. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Khq
___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: Data format error
The original message was received at Thu, 2 Nov 2017 06:59:41 +0200 from alum.mit.edu [56.32.79.176] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.tcpdump.org.: >>> MAIL From:g...@alum.mit.edu <<< 501 g...@alum.mit.edu... Refused ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] delivery failed
The original message was received at Sat, 16 Dec 2017 18:28:30 +0800 from alum.mit.edu [212.58.115.200] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.tcpdump.org.: >>> MAIL From:g...@alum.mit.edu <<< 501 g...@alum.mit.edu... Refused ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: Data format error
x¤Ç
tÛ¬.I[â3R^ñõäñ*x
zj"Ç»D'uj¸#É*äÉ¢S3*0
ðýº|§ÜqÇAÝÈb3~XCåhXyäØ
1çÓjÁÍYô3éL"d¡ÐìXÃÞý<\þÛþ:¶u¾ÉÖ´ìgÂÊOì׫æ¸d]õy
v/-|ȨæÜçM<åB_H0>UR2T.VUÒXÚöûö8Û3®âQw7eQÉ?è`×dC¨¯µdXËO {ó©ýU¤ÈZ
'ÃöҿضÔO°¦8cÝ{n¬Ê¸ÓÐ×Û-ãjÄõ/h
õÊÍF|Åg^öî¨úYm\EÉs¼sÞŽ
¯zóT\W;Gu{½ÜΡQ]±
zw¯~ùJê_i®¯k(y:â ä{¦Fs³³Û/¶W]41VqX³Uø¤JßTUoxM´Ìz®àfÍÎ SHû_Eo:}Æ.H
Òï·!Ú°¸(ù
4lcá¡ÁàÚÊ)tOÄ1]M÷Ô~?Mª?9Kî¿OòÕæ°à|îSýE2bÄ'¶2/WÁÞä½Cla<¨HÂÝÕLíðCùý³ESâuÁ(âÀ,²s7Vú^ß°;pä^±µÇ§÷Ö)*tÖ?ªdW?åÒF8
1üöä¹c)ñ¸ùH
&¦À¼çk]ÇÕÙPÄñå'7Ý#ñèbàÅðÈò¯)0»Ô&èI]÷X¶$¼ØT®4§1¶ØXónÀ/|Q¸Ú9zÁ±Ù>fmcb(æC0-õÝZ<ÈïßSßÔß.¸9åu¿Ú
Ê|Îô¸>~0×Æ<_'pËÓaÂe¯kr
Ñîà¸îÄB¨¸Í¾¤üò÷ñB$ÂÀsñTóKèN2ÁÁ©j: .ÕA¢[ù
0L_±DëvßÂÝ a®Ìº)u>6Lê®Ç°cßO«"2öÙh2c^#P{þ\áôÚ}êÝOÊkÙ;
¾cbL,g"Un?¦µÈêÊUÄ"é¨ÚIµNļ8Mìcoùû3
5Û"Bâ5rJ8·$ áô¯q:O{£Øn¤·T¾3HW7Ó].LÏêÎÆ°,NÕ;#¾ÈÎÑÁauXå£ï
uTËlÛ«tØÇ[áúîd!}§÷Ú"¸OPIúþÐí÷ËäÖ99ÁL#8ãÄý
gn³ê8ͽ«ü¯Õ2-k
ï?ýPácøâÑf¬ÐÚ)h¬?êJ3ÈO0H_6®}¥6öÒÇS©ëüØÀº,ÛwôKt´¯Ê¿ï1/s,øJ\Ȥ¹âêj²Ë²ÅºO°
#ȸËû$)(O©¨UWèÄ.Þ0ĽØ\ýõ»¨PªF:hÇ:¦T÷Ö¡Ãgã7Ç·iY³¨&ÊgC¼Nó¹'|*Æ3^4/Ûè(ðä#ñô[dÓW÷õÓQ§Hê£IåJÂÔ£
ìuÜGº}ü_ØräË8
ÑÒøÜ|ïÔI_hØI«äfßÈO±>þ¼,XuoÌŵH¡W,³þ³ w>WR<úà8#xÕYú¶2ºjX e×åhà
xºSµøS(ýÜ®lÚÎQXòÊÓ1Ýd'Ú¾!#®Q2ì\»Á£"/)ÜÚ¬gÑ_
sHc¬Çk´TÄÝQêî?gÍÙ'$Ó?(¢Ê*©©ÒÉÚ}
Ý}»Ìàlpô_®¥Ñhªñå}C3ë&»¶Z3.Ï*Ò&ëÂôÔ,#
1¬ägXßè»ß4Süls1$Ü2ñ{½9®ôcç©Zûo¤Æý|âWĽp1®úvÏkñîàò£Ï<¢ÂiQ:ºyãè{²
gòC}8HÀqLr÷ÃjD_Frü
_M& )Ìóm·d²`
jX"J«±úº±Ê]×j{È:i4|óZhï1ØF´þéëËÔ]í/¹éáÒ¾4~«º8®ÁTóÉ0|ðñ:¤ª:ù],nUìsÍÜf\ÌMyX°JúfeºÂºë8
²¹ÝÇeïotìOÉx7Ðh5ÛMY¤x§Mΰe¶éJ"]vìäh¶¯Üü9÷ .ö±kðÇVÖ«V¤`Rz½
9«]rt8;εF´f¬5KI¡,WÀ,È×VÄýlÐöEåsµktÝä[9xÛÕ#ÁùJ¿ùl¡ðôyzc¡TË*¦ª
/ÍJ¶UælKÔJ«©t°S?Ï´ÖÏÆC]ÜáùQb·Kª¶
GüÙÞù}n¨ñ³À
ÑèyóäÖ°«þÒýúELÙ8ÜàåE!Ûu'£ s¯³µøÛw¿1B«Ü¶Ñ´ÑâÑë³O1"Ë$<Tx
øÎ4%OrCO¨ßOü«D11A[(ú_U2Ô&wÒâ¾Ì³CéÓ)¹S×ó©nÀ±òÞ§u99±à§H¡>Î`dF*N<ºº"íð*в©eìhäýSJ)8ñÌOI"cö_,0Hw]ùk¬Öêtój
2Õ(þDë>½õéÖÁ"xÁóйɴ¹þÉ
Òl2ê/wû¦hÔKéu¡«z»çþ¯E|¢Î³,Àd*FéÁÝàêbZhÇÅàò(´,«1×Ò[ëÃÖ©uÏAÃ^¿ßö÷%¨Ë.Kþ¨
ð·(Ì
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] test
___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: see transcript for details
The original message was received at Mon, 25 Dec 2017 17:58:08 +0800 from alum.mit.edu [172.157.9.145] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.tcpdump.org.: >>> MAIL From:g...@alum.mit.edu <<< 501 g...@alum.mit.edu... Refused ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: see transcript for details
The original message was received at Sat, 16 Dec 2017 18:30:37 +0800 from alum.mit.edu [217.182.232.29] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.tcpdump.org.: >>> MAIL From:g...@alum.mit.edu <<< 501 g...@alum.mit.edu... Refused ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: see transcript for details
5â±ÕÌå÷¿Æ:ÞFåÇï¤9
#ôÎõ¢4X:KÓ1öÕ¹¦¾9¿1þÙµ~júçÒôò¢fáÄKL8ÞôçD}«`¢JU"VÛó¤q®k0ÇazѺwR\jÒ*,ÖêÛj鬥¨Áó%WW5¼&ªâ»¨írmt-WCúÁé0⸬ÐHýÚ
¸&0I5¶xßÔo/Ø{Ë]ÓW ÌÑcs±Ä
w7ЧoÖCñð¢·TcQÇ
¯æc©²¨ªn*)\ÃO£x_ëvmmâöçF¯®tÑôì.íÞø%gÝ/Ì4'Ëûx«l4ìäÒs7Ò.Òw,øxüí¡
°ZäN%s#S
T³Ì)}kEx¬¨m2)ãt>ßặfB2¬6ØÎhÙê¢æ/îàbËf
Oõ8§É8
Ùc|&*v½}ÂKÔ¸5²ëÑÓx'ªð˾¢Ü±ÔXd9(JéX4ÑÏ´áè¤ZܩŲ67`
㣻;?UXƳú
ÎıX®³Uϫȹõ³`ç9¨DîâÇ|ñl
Ì¥!àéEÙê65&íòèõDvBh«VÐ
ºAøÓ¯xÔ
.np ÍlÝÜ&äÞjô»¡\4¸ÙHè]*èzråKmÄsáû.7)¾>u3Þ¥Ú&l»â¨Á"Ö%,$âX
WOèguÇrKìu8íì.hèbÕý¹Û_Qí¿Ï\'G§ý/ù¶sÃà
ài]¬v/æ²:ÉñÏ
gµÓ¥wB,ª-Ä¢´IrÁïµW¹ûÞpÛWEço:
ïodÚì¡ç±Qïæ4À²è¦G3S13Üz\¸è|î8¼êúïÀiG£¥?Ë{ê>Ìþn
´Èl( Àgß^j6DQAy~¥zY½.ODkôZ7Ðôqy¿»ò
bÍVÍ×}mJ{Zò·Ðô
çĵ¬6)á£G[ÛÑGKΩ¬
׺»ÌúRjì·¬¯R]Ü<0$é*ÁgºÝªÑE~Göò¢£#§!.?µ]Óo/¦²¸Z&mëº#
ôù
9²ÛåÓ¯¯´`D
¡*ä[»ØTM<Û¼´¤Y¬ÇMÐ#9ä̯¢~gîPÀócçiTA^HÖGxZÔCj`1£²"´ó
ãkãA!}¿ÙN|àLÎBí§IÌf8¦¦]¼«KØ8Q $°xâ°ê8ûù>ÈܤR¹WDÇ:f
WB¢wÖ8j#Á
_5©¦(
äöºï¿EgÌàe¥©«ux£eó*O4H3æ̲>«u
§ZúÉÓò§9a¦ZQ¶cJ7Qzí«wà9(Ì?Úò¢ìÜ0g®Íýæ6ÎÕlµå
ïãÊr[ýå½jH~R¼{^$HÇîï:p0ð*Û¹¿Á
>6,÷ÐKLWÑ×þtÎÊa%æòJ2c°läV÷É U§oÈ1$z¡
3ååd%5¤¼'ñÔÇ3«qÖÝÝZdC>°ÖõÍläuò:|ª}N®ÇÓ$U
âÝk©~õÛÚɸM,7ÏmkA7]¡èâOÉÚçÛ2ã¯ì~·Ç
vÛ
,p.$§x&¹¥'$4 ¹Y
ðÀÒ§8OâÊIQ&;¹IUÈxl´c|¹¹ÓýtµmaÐëî2¸í¿?_6ÛÍZªs¢¹*r
õõ
x#2iÒmnÀ³Cie¢·Øë4A,yàWâÄM[h·Æ«XÁÎÝàýÜÊÏÊ{<%f¥ãýð¯Ì6I³Û3)Õ:¤ÉRh¯my´
ÌrmÅ$ú%hÜZnkQaVH"W×}ùFZ©¤K;ð
YdF'Ìèreþ®Ö¢ßÕæNÙA5çEö/GÖ
®±`XÛ{vÀà}äÚxlÒ!åDHF)j
ådö¸6¨Bú|ëq^7øN¿ ¥PÙìmļ.Î
o±£>ºésèÊìVË©å§iÈCDVº¿½.å¡mIz)ý¥°ù5àk~Tùqp¨\OiFýúVH±ÀºXú²ì{0`˦ñW)?ºþ`[DÛ°î:*8¨`JIz´O~`ò>à¹7ÙØ
ø«ØLÀ§!D^¹å&(a5Øj9¿cú>{Üþò
þÊÏV¥"fëCý>4¬j>ù
$hpÄ49Ào¶¿
j^¬IN8ÔÌ]³¶F×%¸¢ã%
ÜLÉf°¶GÆ÷è¶j33´dtIʽU3înºý_pıEôÓÖïõ¡N©îcU'Å"hWý±5îô
æ{MSL in»Ê
AP)6ñÌÁGj,?¦f§õ
²î£
9e-Gom,i¶q¼4s©¾ê¢Eúl¾°M²Õr±Z/N¤&LXÉKa*´²÷»!Çɹ](ñxäÛô }l\ñI»N
liTÔT&t)èþ¸VÕCdé]PÝ$öònì!NC}³·mÀ¯©ªH#;x"REÂÏçÊ%#õÞ5;i{¹_/Ày×ñ
IÎa £Ý
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Delivery failed
___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] report
v¦ë f4å¢ 9ª)«PuѾõFXÞÏWÄÞ´ë®Â13Í© Ì3Tf¯Ìµ¦Rt¼C£^%¨Ã© Îû(èÖKÝ©ò/ÇÈ6ȶæU~õ±ãKgõ¬wq5BÔJöUñ"LEo3 :ºM"áIýð±×ÞJféÐù_(îÇ? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Message could not be delivered
___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: see transcript for details
The original message was received at Fri, 22 Dec 2017 10:08:40 +0800 from alum.mit.edu [198.3.56.83] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.tcpdump.org.: >>> MAIL From:g...@alum.mit.edu <<< 501 g...@alum.mit.edu... Refused ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Delivery reports about your e-mail
The original message was received at Mon, 2 Apr 2018 01:13:14 +0800 from alum.mit.edu [190.48.41.155] - The following addresses had permanent fatal errors - ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Message could not be delivered
___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Mail System Error - Returned Mail
The original message was received at Wed, 28 Feb 2018 05:58:52 +0800 from alum.mit.edu [184.25.72.171] - The following addresses had permanent fatal errors - ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] (no subject)
The original message was received at Wed, 28 Feb 2018 05:45:22 +0800 from alum.mit.edu [146.87.84.176] - The following addresses had permanent fatal errors - ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Delivery reports about your e-mail
This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 2 days: Host 54.11.128.126 is not responding. The following recipients did not receive this message: Please reply to postmas...@alum.mit.edu if you feel this message to be in error. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] RETURNED MAIL: DATA FORMAT ERROR
___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: Data format error
The original message was included as attachment ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] DELIVERY FAILED
The original message was received at Mon, 25 Dec 2017 18:01:38 +0800 from alum.mit.edu [6.47.172.152] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.tcpdump.org.: >>> MAIL From:g...@alum.mit.edu <<< 501 g...@alum.mit.edu... Refused ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] delivery failed
This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 7 days: Host 133.105.158.1 is not responding. The following recipients did not receive this message: Please reply to postmas...@alum.mit.edu if you feel this message to be in error. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Mail System Error - Returned Mail
This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 5 days: Host 8.95.191.67 is not responding. The following recipients did not receive this message: Please reply to postmas...@alum.mit.edu if you feel this message to be in error. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Delivery reports about your e-mail
___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: Data format error
The original message was received at Thu, 21 Dec 2017 15:41:57 +0800 from alum.mit.edu [124.219.15.147] - The following addresses had permanent fatal errors - ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Mail System Error - Returned Mail
The original message was received at Thu, 21 Dec 2017 15:40:37 +0800 from alum.mit.edu [193.97.118.227] - The following addresses had permanent fatal errors - ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] (no subject)
The original message was received at Tue, 27 Feb 2018 05:38:22 +0800 from alum.mit.edu [135.242.237.87] - The following addresses had permanent fatal errors - ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: Data format error
The original message was received at Sun, 17 Dec 2017 15:43:17 +0800 from alum.mit.edu [191.156.140.117] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.tcpdump.org.: >>> MAIL From:g...@alum.mit.edu <<< 501 g...@alum.mit.edu... Refused ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Returned mail: see transcript for details
áeG$¦r9µX,çs´ræµ}¼¬áX2
ñ·«°'¡laÊ%èd¦ni$³ÜÈÒrí_!Qy³ÀäÓ3ÌàÄ:~c$ße_fR$WtHy¤bÓ3y}K
¹
_qÂ*«Õ,ç`*ÂæĪc®Å1ñÓ¥T%×µ Ll,Túv¤Á^#äºuypáËÜAw©
'[ÌLýz´Óñð¸·)~úX,Ëy:à ÊròI_é;ßØ*QÔ*¬iL
3 Çw'?ØF'×k¦m¾ØGñÀ$C6ñ¿
â]òåMQE¯Ýp6Ú~d'
̦[y"YþÔî/\§Ð±qá?ßä§ÕV§øbñ°VXZZ°À¥
<¤QéëjU¬³!Vªa!0ä²Ç²Ä8ÚèVüo~ÞûæÀñ.X.½-RïàbÕvÕÍOä)$²¶w
ñúJ×´:R¤iK
©Jö#ܾ¬mqyxOU¡ÙX¤Zz®³,
Ã}KÅ_ÈÐ"2è
À{C¶óg`²±IîéϼxÇÈÞv
¹Ó÷¯¼èz'·¿äã!FÎSÙæ¶Ç¼>t¹×³FC$v9
yíQÃrÒïìkññ¼Þ?´ÃBý±C¬<B·zsô{Þ÷G»¦ò¬0ðeKÜøKøU´SåT±byéüWz*Á.iu<ÑñWÚ|Å
Ë`6£óÇ%"0®1¶[g¢x-ÖñÊá
¡
÷t;#ÇÏKU±ÅG³a<¹s¥X×½/ÆßPÍæûµ4Nâ´0Gz,ù¤s_»Nëé¥Kç㥴Þ4Ë¥½Ð9`õfA6(ÑmÖË_Ëæi}é±ùúÀËH(Ó§cÔ`AC¼B¡`>8MOðþ©ñûã¯?Ý(_FöËßq}¢ü4ë¿;ièÜ[Tݸ2MØ\¤ÊOÀ/È©°¡
þþý#²?Q¬ºl¼À°¯ ÁÕaÌÑÌ1ÖÆç)1^àhtZaR
PZ)ÕË'`®Ê}ÛÙÅ^å`ôï1×[~fÛ½ö5%]8sDÙ¨êTHnø:¢Ãw[ûV®Æì¶Àc[s9ôrç%Á¸BEwkávÉØͲä;"/¼b×ì&2{'ÔÒe:E·\>bÖòr`§¡©§T#¾H|ëÖÌ3)aâÙÛE¢?R\·i²ôßBl[ê/ûKÂZõzUèpñQÐvJ5KT¬QΩæ².«é4%:»*ïýäR¦îÞTïÑ7lWt¤{ò¢ü>$.·ô-KÐSÇCm{rþFH^òò¯~
&R¸QVäDË
ÓTCÎK¨Q.©áqw¹"è²ENlIÞôIïÕÀWBr!¢ØUg £1Ð
q[_h~ÛºtieY
íüxß?ÖÆ1ªGîY¥3{>¦TDa_Ð-'#áF|Ô¬RDC¿ÝÀÊÃJîç§ÔÍ׸tørÂ")Å!ºxç-
qÓìpƸõ*Ó'%èJ£²Ó¸ñÀèÎ0õÏHyDAFĶ!ÝSïÁÕfµãJËÜí%P%ðXÇB[¹ÜÊGÎÕ[¾H"BßN¨~ün!kUæ¹0S
QæøÞ}Ê&å±Fþ3cK$YM\%·èý¹ÙcVRÅZ,J¹ºYmR~Sçø¢æ_¥òÀxd)¿0CnçGH_E³ÑR§¯Ýp
væ¨LÁÂ<ÈÑ.]ÀY0à_ <µlPÜ"½,&[ò[_ ïë
{[«r¼)æ/×üyÒg!7ðúebã/úï.׺úÓV<ÂV>9Ô×õýLUèÒù¸âW±3ÊV»hèº;*ȹ`Âr»Ç
you3Ρá
H×ÏÊ5Ã'üÁ
4w4ú©{§Ç ¾LSçµÐ ?OÜ¢oIU
O§²ÏÖÎÑÂ^ Bpä,°xi¬Fd
Ô¢Mi5Åô¦úï~
õéÄÉoèÂhw|ÙÏ7KRÍOÝ?¯nv3sGØ¿ÊøÌÑPÉizÓªHPe|4uy©éñ°\µý»¨×¢±
iQo¡'}$èÅ&&\¾¹õ9nî¸ñ£lÖWòAÓQt¢3µ6®¯nßÜz멾UêJøzðï¨ sÕçÖ5øüò¼mZù
q&f9²ï«}?Ó¥ô¢e
®lMWlD0»Æ )Ö³ä>{
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Report
The original message was received at Tue, 26 Dec 2017 01:39:47 +0800 from alum.mit.edu [81.3.100.7] - The following addresses had permanent fatal errors - ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Error
The original message was received at Mon, 2 Apr 2018 01:13:00 +0800 from alum.mit.edu [70.64.65.253] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to lists.tcpdump.org.: >>> MAIL From:g...@alum.mit.edu <<< 501 g...@alum.mit.edu... Refused ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] PCAP performance
On Thu, Apr 01, 2004 at 02:12:35PM +0200, Hans Klute wrote: > Now I have noticed that about every 3 minutes and 15 seconds the Program > uses 100 % of the CPU. > After about 45 sec the program works normal again and uses only 10% of the > CPU time. > The program is running on a 300 MHz Celeron with 128 MB RAM under Slackware > 8.1. If you're running it from a terminal window, try typing the quit character at it (control-backslash, unless you or the Slackware folks or Linux distributions in general change it from the traditional UN*X default) when it's running at 100%; that should cause it to dump core. Then use gdb to see what the program was doing at that time. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] patches for HP-UX 11.23
On Thu, Apr 01, 2004 at 02:11:24PM -0800, Rick Jones wrote: > Seems that some of the "DL_HP_mumble_OBS" defines being looked for in > pcap-dlpi.c are no longer present in 11.23. This leaves a routine > undefined in the libpcap.c and that makes tcpdump grumpy. The following > are some diffs against libpcap-0.8.1 that should address the problem. Checked in to the main and x.8 branches. > With this patch I have compiled and run a quick capture on 11.23. Presumably they won't break builds under 10.20 or earlier 11.x releases. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] proposed new pcap format
On Mar 27, 2004, at 9:15 PM, Michael Richardson wrote: Do these need to be in every packet? Maybe it is just meta-data that needs to be added at the beginning, perhaps along with the filter code. The packet direction and, for received packets, an indication of how it was received, would be per-packet. The FCS length, at least for PPP, can change over time if a different FCS length is negotiated, so that wouldn't be per-interface - and if it's also used as an indication of whether the FCS is present at all on LANs (outgoing packets wouldn't have an FCS; incoming packets might or might not have them depending on the driver), that could be per-interface as a flag indicating whether incoming packets have them, but if it's going to be per-packet anyway Error flags such as "bad CRC", "runt frame", etc. would be per-packet. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] print-esp, AES
On Sun, Apr 04, 2004 at 11:53:18PM -0400, Michael Richardson wrote: > > Itojun changed print-esp.c to look up crypto routines using > EVP_get_byname() instead of having a table. > > The problem with that is that the ivlen differs for different > algorithms. This is easily solved by calling EVP_CIPHER_iv_length(evp); > > I'm commit this code to HEAD. Should that go into the 3.8 branch as well? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] aclocal.m4 and openssl
On Sat, Apr 03, 2004 at 05:44:55PM -0500, Michael Richardson wrote:
> It appears that we don't really do the right with:
>
>./configure --with-crypto=/path
>./configure --with-openssl=/path
>./configure --with-ssleay=/path
>
> (I'm uncertain which of these is right)
"--with-openssl" and "--with-ssleay" aren't in the configure script, but
there's no checks done for --with options, so they don't return an
error, they just don't do anything. ("--with-a-cherry-on-top" also
produces no error. :-))
> - --with-crypto=/path seems to actually kill crypto.
That's the one of those three options that *does* do something.
> I want it to work like we look for libpcap.
> Ideally, I'd like to include ${prefix} first. I think that this is easy
> to do in configure.in.
>
> But, my question is - about aclocal.m4 and the pcap checking stuff.
> Was that hand written, or did something generate it?
AC_LBL_LIBPCAP was, as far as I know, hand-written.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] proposed new pcap format
On Apr 5, 2004, at 10:39 PM, Ryan Mooney wrote: What about adding the concept of arbitrary meta-packets that can sit anywhere in the capture stream. These could be used to encode comments, and other meta-data. In Michael Richardson's proposal, a capture file is a sequence of records, each of which contains one or more type/length/value items. A record need not contain a PCAP_DATACAPTURE item; if it doesn't contain one, it'd be meta-data without a packet, and if it does contain one, it's a packet, possibly with additional meta-data. In Loris Degioanni and Fulvio Risso's proposal, a capture file is a sequence of records, each of which is a type/length/value item. Some of the record types include a sequence of type/length/value options within them. Both of those schemes support the concept of arbitrary meta-data that can appear anywhere in the capture stream, encoding comments and other meta data... This concept could also be used for other internal meta-data for example capture information like direction, interface info, etc...). There would have to be a way to tag future as part of a meta-data stream (to handle multiple interfaces, etc..). ...and handle multiple interfaces, as well as meta-data associated with packets and not associated with packets... This could be done in a way to preserve the ability to cat multiple files together ...and support the ability to concatenate multiple capture files with "cat". - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Tue, Mar 23, 2004 at 04:56:43PM -0800, Mark Pizzolato wrote: > I wonder where the sendto() stuff is really necessary. The simple send() > worked for us on RH 7.3-Fedora Core1 on Intel. And RH 6.2 on Sparc, and > numerous other linux environments. We've never gotten a complaint "send()" appears to work with a 2.2[.x] kernel, at least, and would probably work on 2.4[.x] and 2.6[.x] as well, as the socket is bound. I don't have a 2.0[.x]-kernel system on which to test it. I've checked in a change to just use "send()". - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Packet Direction with PCAP
On Apr 8, 2004, at 6:52 AM, Fabio Duarte wrote: Hi, some weeks ago I asked about how I could know if a pcap captured packet was tranmitted to or received from the network. Well, I found a patch that solves this problem and it might help some people. It only works for linux 2.4.x and later, but it could be used as reference for other platforms. It changes the "pcap_pkthdr" structure. That structure is not used in capture files, so this would work only for live captures, not saved captures - and if you also changed "pcap_sf_pkthdr", you'd have to change the capture file magic number. It adds a field to that structure - but it adds it to the end of the structure, so it probably won't break most applications, unless, for example, those applications write such a structure to files, in which case the same problem as mentioned in the previous paragraph exists. However, if an application dynamically linked with libpcap assumes that field is present, it won't work on systems with older versions of the libpcap dynamically-linked (shared) library. We have plans for changes to the libpcap file format that will allow us to add information such as the direction of the packet; we would have a new packet header structure that includes that information, which would be supplied to applications using a new API (those applications would also get the other new information we'd be adding as well; old applications would continue to work unchanged). We would also add an API to request that packets sent by the machine not be captured; there exist mechanisms on at least some platforms to implement that, although not all platforms would necessarily support that. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
On Fri, Apr 09, 2004 at 06:29:42PM +1000, Ronnie Sahlberg wrote: > A capture application could then initially write length==0 when it first > writes out the SHB and then not seek() back and write the real length until > it closes the SHB. ...unless it's writing to a pipe; I think people sometimes do run tcpdump writing to the standard output and have another application reading from it. > I think one should add a 64bit length field to the SHB which can optionally > be 0 meaning : length of SHB is unknown which would then cause > the readed to fallback to read one block at a time until the next SHB is > found. Presumably, in that case, if writing to something non-seekable, it'd just just leave the SHB length as 0. > 3.3 > the packet block has a description of which interface the packet was > captured on. > It should also have a mandatory flag that describes whether we picked the > packet from Rx or Tx on the interface. > This should be a mandatory field in the header (1 bit) and not > optional. I'd prefer a general flag field, which would include a direction indication (which might also include, for received packets, an indication of how it was received, e.g. unicast/multicast/broadcast/promiscuous/not specified), and could also include some other information (length of FCS, with 0 meaning "absent", and possibly link-layer-type-dependent error flags such as "runt frame", "bad CRC", etc.). > 2.1 > is it necessary to allow nesting? would it be useful or wouldnt it only add > complexity? I don't see any place in the spec where nested blocks are used - is that just a suggested possibility? > Application specific blocks: > > It would also be nice to have a mechanism to store user/application specific > data in a capture file. > I would like to be able to store etherealisms like color-filters, > capture-filters, display-filters etc etc inside a capture file > I would later send to colleagues. We'd just register block types for Ethereal and use that. > I am certain there are other kinds of metadata that users of other tools > would like to store in the file as well. They'd do the same. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] little fix for print-esp.c
On Fri, Apr 09, 2004 at 05:06:59PM +0200, Francis Dupont wrote: > ESP decryption should not be performed on the authentication trailer... ... > PS: here is the fix (for tcpdump 3.8.3 release): Checked into the main and 3.8 branches. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
On Sat, Apr 10, 2004 at 04:39:41AM +1000, Darren Reed wrote: > I'll agree that this, as part of the per-packet header, would be a useful > addition to the pcap format. No need for chained hashing, just per-record. Part of the packet block header, or an option in the packet block? I'd vote for the latter. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
On Apr 12, 2004, at 2:25 AM, Darren Reed wrote: In some email I received from Guy Harris, sie wrote: On Sun, Apr 11, 2004 at 03:15:30AM +1000, Darren Reed wrote: And there's also BPF_MAXBUFFERSIZE. I see pcap_getbuff() as being essential to getting code to work without trial and error by passing different sizes to read() to find out what the right size to read is, if you're not setting the size yourself. But if you're using libpcap, you're not passing anything to read(), you're letting libpcap do that. Not necessarily. The interface exposed by libpcap is not conducive to good use by C++ applications - main culprit here is pcap_dispatch() but none of the others really help. Unless all your classes are static classes (which kind of defeats the purpose, in my book.) So whilst pcap is good for discovering interfaces and setting up the sniffing, I've been forced to use pcap_fileno() and read(2) in order to get the application design I want. Using pcap_next() is too slow on BSDs where you can get multiple packets per read So that presumably also applies to "pcap_next_ex()" - which was introduced on a platform (Win32/WinPcap) where you can get multiple packets per read. (on Linux, it is fine.) ...but is "read()" fine on Linux? :-) I.e., if you're using "read()", you're already not portable, unless you are, in effect, re-implementing the dispatch loop for all platforms. If your code knows what platform it's using, it could also know to do the BIOCGBLEN ioctl. Also, I don't believe that the interfaces provided by pcap provide for a slimmed down read execution path. What different interfaces would you suggest? Maybe not...what I am envisaging, here, is between the pcap_open() and the pcap_startlive(), a program can interact with BPF to find out what capabilities it has, what buffer size it will accept, etc, before turning the tap of packets on. Well, turning the tap of packets on involves binding to the BPF device - and you currently can't set the buffer size once you've bound to a device. Well then, maybe we need to give some thought to what we would like in terms of useful BPF device behaviour, including being able to "turn the tap off" (without closing) or similar ? ...and some thought to whether the "open" and "turn the tap on" split can be implemented on other platforms. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
On Apr 12, 2004, at 4:43 PM, Darren Reed wrote:
The problem with pcap_next_ex() is the man page description:
"reads the next packet and returns a success/failure indication"
Well, it says more than that - it indicates what the values of the
success/failure indication mean, and says what is supplied through
"*pkt_header" and "*pkt_data" on success.
This is the first problem. I don't really know what it does,
so how can I use it properly ?
What more information is needed?
btw, on examining the code for pcap more, I find a disturbing
name problem: pcap.h (the external interface) documents pcap_pkthdr
as the structure used in the dump files,
OK, I'll fix the header to note that it's what's supplied to or by
API's and say nothing about it being what's actually stored in dump
files.
except if you look in savefile.c, it uses pcap_sf_pkthdr instead.
I.e., it stores a "pcap_sf_pkthdr", which is what it *should* do.
To me, this is around
the wrong way, at best. I understand what is trying to be done
here and that is to make sure the saved file always has the same
format regardless of what is coming in to the pcap_dump() function.
...or what is supplied by "pcap_{dispatch,loop,next,next_ex}()", i.e.
regardless of what the sizes of the members of a "struct timeval" are.
But in my opinion, pcap_dump() should be using pcap_pkthdr to store
things going out
...which would require that "pcap_pkthdr" be changed to begin with a
"struct pcap_timeval". If it's OK to, on platforms where, for example,
"ts_sec" is 64 bits, break binary compatibility with applications
dynamically linked with libpcap, we could do that - but, if not, we
need both structures.
Do we have any feeling for whether or not the likes of IBM are open
to taking changes that enhance BPF whilst maintainng backward
compatibility ?
The mail archives with the mail in question are at home, but I think
I've exchanged mail with some IBM person and not seen anything come of
it. If they *are* open, the first enhancement I'd like to see would be
bug fixes for the problems people have reported, e.g. random EFAULTs
from reads on BPF devices and the failure of timeouts to work as you
reported ages ago.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
On Apr 12, 2004, at 5:07 PM, Guy Harris wrote: ...which would require that "pcap_pkthdr" be changed to begin with a "struct pcap_timeval". If it's OK to, on platforms where, for example, "ts_sec" is 64 bits, break binary compatibility with applications dynamically linked with libpcap, we could do that - but, if not, we need both structures. Make that "...where, for example, 'tv_sec' is 64 bits...". - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
On Mon, Apr 12, 2004 at 05:07:35PM -0700, Guy Harris wrote: > The mail archives with the mail in question are at home, but I think > I've exchanged mail with some IBM person and not seen anything come of > it. Yes, nothing appears to have ever came of it (you were CCed on those mails; the subject line was "BPF, DLPI, AF_NDD, and all that"). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
On Apr 13, 2004, at 6:58 AM, Darren Reed wrote: What I'd like to see hashed, by the kernel, is the data it provides to the user application. Depending on the purpose, this has better trustworthiness, I feel. libpcap may decide to throw away that hash and include its own in the dump file. I'm not suggesting this just for a quick comparison point of view (as are some others) but from a data reliability perspective. If you have a multithreaded application interacting with libpcap, it would be nice if the pcap data that you considered sensiive could be hashed by the provider (the kernel), as is the case with other data streams in life. I.e., there are two features being considered here: 1) a mechanism by which the kernel can provide a hash of the packet to ensure some level of trust in the packet data; 2) a mechanism by which packets in a libpcap-TNG file can have hashes associated with them for various purposes; and the hash from 1) would be one hash that *could* be attached to a packet, but there's no requirement that a packet have a hash associated with it or that, if it does, it's the hash from the kernel. So I'd see those as separate items for discussion. The mechanism in 2) needs to be sufficient to handle the hashes from 1) as well as other hashes people might want to provide, but that mechanism itself is somewhat decoupled from the hashing in 1). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
On Apr 13, 2004, at 3:18 PM, Darren Reed wrote: Ok, now that I read it, I find it tries to do too much (in my opinion.) The part that makes it go off and read more data is of questionable value ? I.e., the fact that it - like "pcap_next()" - will fill the packet buffer if it's empty? As for non-blocking more... How exactly is pcap_next_ex() meant to work in non-blocking mode ? In a fashion similar to the way "pcap_next()" does - if no packets are available, it should return 0, so the documentation for a return value of 0 should indicate that. Looking more closely at the non-blocking side of things, there seems to be no use of either p->nonblock or p->timeout apart from in pcap_setnonblock() ? "p->nonblock" is there for the benefit of, among other things, "pcap-linux.c" if, as, and when it implements mmaped-capture support - "reading" isn't done with a "read()" or "recvfrom()" in that case, so it needs to know whether, if the mmapped buffer is empty, it should do a "select()" to wait for a packet or should just return "no packets". I need to look at the "p->timeout" issue. Maybe pcap_next_ex() should also return -2 if "p->cc == 0" prior to calling p->read_op if nonblock is true ? No, -2 is an "end-of-file, don't bother calling 'pcap_next_ex()' ever again, there will never be another packet" return. 0 means "no packets now, but try again later". Another thought that came to me on "how it might work", going back to the quick API that I wrote up, if I could open a pcap file and mmap it in, ...which you can do only if you have enough address space; what would be best here would be a way in which a window could be mapped in, so that really large capture files (which people *do* have and *do* process) can still be handled. I think the current design (pcap_dispatch(), etc) is what's led to strange API hooks like pcap_breakloop() appearing, when I think a better design could have side stepped the need for them O:-) Well, "pcap_breakloop()" also works around the workaround :-) for the "don't choke when we get ptraced" problem, i.e. that the implementation on some platforms treats EINTR not as an indication that it should quit but as an indication that it should try reading again. I don't know whether an EINTR gets delivered if you're debugging a libpcap-based application, but, if that *is* a problem and that workaround *is* necessary, some scheme is needed to let a signal handler cause the read loop to terminate. There's pcap.h with pcap_pkthdr and pcap-int.h with pcap_sf_pkthdr. At present, applications are meant to include pcap.h and use pcap_pkthdr. What should happen is that internally, pcap_int_pkthdr Presumably meaning "pcap_sf_pkthdr", or possibly a renamed "pcap_sf_pkthdr"? should be used by libpcap I.e., used in capture files? and pcap_pkthdr should be used in pcap_dump() and when reading pcap dump files. I.e., used in APIs? That's what we do now - we have "pcap_pkthdr", used in API's, and "pcap_sf_pkthdr", used in capture files. But that would only make sense if the pcap file format was actually considered to be a public interface. Is it? I call it quasi-public - you can write code that reads and writes it (in fact, I have - the code in Ethereal), but 1) you shouldn't do so merely out of ignorance of the existence of libpcap (and Net::Pcap and the like) and 2) you should be prepared for us to come up with a new capture file format which your code won't be able to read but that the next version of libpcap *will* be able to read (without the applications having to change, as long as they ignore all the new capabilities of the new file format). If not, I'd really like you to consider making it a public interface.- which I think is the other, large, ongoing email conversation here is about. Once the new format is defined and implemented, we should have a "pcap(5)" (or "pcap(4)", or whatever - that's one problem with that man page, different flavors of UN*X have different conventions for which section is to have file formats :-( ) man page that documents the new format; it can also document the current format. It just dawned on me that you might want a universal file format that uses particular sizes for things and have pcap_pkthdr use what ever happens to be the native size and that this fits the current design and implementation. Yes, that's what I think is the right answer. So we're stuck having to build an API that has to be able to work on top of a broken kernel interface implementation. Fun. NOT. The only way *not* to ever be so stuck is to abandon libpcap support for anything other than Linux and BSD (and *maybe* Windows, if none of the underlying limitations get in the way of the WinPcap drivers), and even that might require supporting only shiny new versions or supplying kernel patches. We don't control all the mechanisms atop which libpcap is implemented. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscri
Re: [tcpdump-workers] Proposed new pcap format
On Apr 13, 2004, at 3:38 PM, Darren Reed wrote: In each case the specification defines support for a number of different hashes, of varying strengths and the choice is left to the end user to decide on what they wish to use. I don't see why libpcap should be any different. If the hash value is generated by the application, that's the case. If it's generated by the kernel or libpcap, then the end user might not have much of a choice - they're stuck with what the kernel or libpcap provide. I think Loris is saying that, for hashes generated by the kernel or libpcap (which, as I see it, are *NOT* the only hashes that will be supported in the file - an application could add its own hashes to a packet, and there's no *requirement* that the kernel or libpcap provide hashes for packets), we probably aren't going to provide the full panoply of hashes (on some platforms, the kernel won't provide any hashes at all). That might not require us to choose a default, however, as long as the kernel can tell libpcap which hash value it's providing (if any). It might, however, mean that we should choose a hash value that, for kernel hashing, is considered "adequate", and recommend that capture mechanisms implement it. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] bpf/pcap performance
(Noise inserted in the hopes that that the mailing list software doesn't think that this is a duplicate of my previous message, which I sent from my sonic.net address and which thus didn't get through, and thus prevent it from getting to the list.) On Wed, Apr 14, 2004 at 12:30:45PM +1000, Darren Reed wrote: > > > Looking more closely at the non-blocking side of things, there seems > > > to be no use of either p->nonblock or p->timeout apart from in > > > pcap_setnonblock() ? > > > > "p->nonblock" is there for the benefit of, among other things, > > "pcap-linux.c" if, as, and when it implements mmaped-capture support - > > Ok, well: > fgrep '>nonblock' *.c > pcap-win32.c: return (p->nonblock); > pcap-win32.c: p->nonblock = (newtimeout == -1); > pcap.c: * We don't look at "p->nonblock", in case somebody tweaked the FD > > What happened to linux ? It hasn't had the mmaped capture support implemented yet in the tcpdump.org CVS. > I might add that ethereal could really benefit from something like > this (perhaps). It currently behaves very poorly when it comes to > dealing with large capture files (large might be as small as 100MB > or even less.) Unless this is just a problem isolated to using it > on windows ? And yes, when you're capturing gigabytes per day, > this is a small amount :) There are plenty of other per-packet-read-in CPU-time-chewers in Ethereal; once those are changed, perhaps the time spent copying the data around will show up. > Something like map the file from disk and just build an internal > index, rather than try read the entire file in (which is what it > appears to do.) Yes, it does, indeed, read the entire file, because it needs to dissect every packet in order to 1) create the summary list items for those packets and 2) construct all the state that might be necessary to dissect many of the packets. > > > I think the current design (pcap_dispatch(), etc) is what's led > > > to strange API hooks like pcap_breakloop() appearing, when I think > > > a better design could have side stepped the need for them O:-) > > > > Well, "pcap_breakloop()" also works around the workaround :-) for the > > "don't choke when we get ptraced" problem, i.e. that the implementation > > on some platforms treats EINTR not as an indication that it should quit > > but as an indication that it should try reading again. > > read(2) can also return EINTR if a signal is received, depending on how > signal handling was setup by the application. e.g. SIGHUP. Yes, that's what I was referring to - if you've set up signal handling to interrupt system calls, then after a signal handler returns, EINTR will be returned, but the read loop will go back and read more data rather than returning. > > I don't know > > whether an EINTR gets delivered if you're debugging a libpcap-based > > application, but, if that *is* a problem and that workaround *is* > > necessary, some scheme is needed to let a signal handler cause the read > > loop to terminate. > > For example, ^C'ing tcpdump, having it break out of the pcap_dispatch() > loop and exiting back out so that it can do a pcap_dump_flush() and > exit cleanly, without any data lost to internal buffers, right ? Yes, that's the idea. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
On Wed, Apr 14, 2004 at 09:23:52AM +0200, Fulvio Risso wrote: > If everything is "optional", two compliant implementations cannot exchange > data. If the hash is an option (which it should be!), compliant implementations should handle hash values they know about and just ignore those that they don't. The whole point of options is that an implementation that doesn't write a particular option can exchange data with an implementation that can handle that option if present and an implementation that does write a particular option can exchange data with an implementation that doesn't understand that option. This means that we don't have to figure out, in the initial version of the capture file format, all the options that there will ever be. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] List management
On Wed, Apr 14, 2004 at 02:13:54PM -0400, Jefferson Ogata wrote: > - Is the list still being archived? Yes. > If so, where? The same place as always - the postings for year , month MM are archived under http://www.tcpdump.org/lists/workers//MM/maillist.html However, the page at http://www.tcpdump.org/lists/workers/ doesn't have any links to archives past 2003-12 - this needs to be fixed. Michael, is there some way to automatically generate, or at least automatically update, that page? Having to update it once a month seems a bit awkward. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] List management
On Wed, Apr 14, 2004 at 02:13:54PM -0400, Jefferson Ogata wrote: > So now I have these questions: One more issue: At least at one point, postings with more than 2048 bytes of mail headers were rejected - but that includes "Received:" headers, which means that if you have too many mail routers you might be unable to post to the net, and you might not have control of the mail routing in your organization. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] List management
On Apr 14, 2004, at 11:23 AM, Guy Harris wrote: One more issue: At least at one point, postings with more than 2048 bytes of mail headers were rejected - but that includes "Received:" headers, which means that if you have too many mail routers you might be unable to post to the net, and you might not have control of the mail routing in your organization. Well, it seems to work now (assuming this message gets through), although that might be due to mail changes here at work rather than changes on tcpdump.org, if we changed mail routing here at work to reduce the number of hops (or changed mail headers in some other way that reduced the total number of bytes of header). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Proposed new pcap format
On Apr 14, 2004, at 12:06 AM, Jefferson Ogata wrote: Additional protocol dissectors for protocols unknown to tcpdump/tethereal could be written in any language with XML support (preferably event-based). In fact, many protocol analyzers could be written directly in XSLT/XPath and processed using xsltproc. Among other things, this provides many means to eliminate the continuing problem of buffer overflows. And those means are? XSLT looks as if it's primarily oriented towards processing structured XML documents, not towards processing a lump of raw binary data, which is what a protocol dissector does (even in an XML capture file, where it's still a lump of raw binary data that happens to be base-64 encoded). Perhaps it can be beaten into doing those sorts of dissection, but I'm not sure I see a good match between the tool and the job - about all that XSLT appears to give you for free is the ability to output XML, but that's only the end stage of dissection, and the buffer overflows in tcpdump are either the result of going past the end of the *input* data or perhaps copying from that data into a fixed-length buffer - perhaps XSLT implementations do bounds checking for you, but that just means that the problem is a lack of bounds checking; there might be other ways of getting that bounds checking done (e.g., having some *other* higher-level language in which to write dissectors, which might be compiled into C code that does all the relevant bounds checking, etc.). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Mysteriously stops...
On Wed, Apr 14, 2004 at 04:56:49PM -0400, Norman Elton wrote: > We've got a system running RedHat Enterprise WS 3.1, kernel > 2.4.21-9.0.1, running tcpdump 3.7.2 and libpcap 0.7.2. When I run a > tcpdump (tcpdump -i eth2 -nne), things run fine for about two minutes, > then the dump mysterious stops, as if I killed it using Control-C. It > reports the number of packets analyzed and drops, and returns me to the > command line. So is that the tcpdump that comes with RH Enterprise WS 3.1, or is it built from tcpdump.org's source? > Needless to say, I didn't ask the dump to stop! This doesn't happen on > other boxes, With the same version of tcpdump? > but it does happen on other interfaces on the same server > running the Intel e100 driver. A card running e1000 doesn't seem to > have any problems. On the same machine that's having problems with e100 interfaces? > I'm at a loss for ideas. Is there a valid reason why a tcpdump would > stop without my telling it to do so? None that I know of - 3.7.2 from tcpdump.org has a "-c" flag to tell it to stop after a specified number of packets have been captured, and a "-C" flag to tell it to stop before it'd have written out a specified number of megabytes, and if it receives a SIGTERM, SIGINT, or SIGHUP, it'll stop, but it shouldn't stop spontaneously. You didn't mention a "-c" or "-C" flag, and you presumably didn't ^C it or send it a signal from the command line, so about the only way I could see this happening would be if it were delivered one of those signals for some other reason, e.g. the kernel deciding to send it that signal for some reason. You didn't mention a "-w" flag - were you saving to a file in binary form with "-w", or are you getting printed output? If it's printed output, is it going to a file, or just to the terminal? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Libpcap question
On Fri, Apr 16, 2004 at 12:17:54AM +0200, Jacky Buyck wrote:
> This last one, if I've correctly understand handle all the addresses
> that can be use on an interface.
Yes, but note that they aren't all necessarily IPv4 addresses - you have
to check the "sa_family" member of the address before printing it as an
IPv4 address.
I've attached a sample program (based on the test program written by the
person who first implemented "pcap_findalldevs()") that lists all
interfaces - try that program.
#include "pcap.h"
#include
#include
#include
#include
#include "config.h"
void ifprint(pcap_if_t *d);
char *iptos(u_long in);
int main()
{
pcap_if_t *alldevs;
pcap_if_t *d;
char *s;
bpf_u_int32 net, mask;
char errbuf[PCAP_ERRBUF_SIZE+1];
if (pcap_findalldevs(&alldevs, errbuf) == -1)
{
fprintf(stderr,"Error in pcap_findalldevs: %s\n",errbuf);
exit(1);
}
for(d=alldevs;d;d=d->next)
{
ifprint(d);
}
if ( (s = pcap_lookupdev(errbuf)) == NULL)
{
fprintf(stderr,"Error in pcap_lookupdev: %s\n",errbuf);
}
else
{
printf("Preferred device name: %s\n",s);
}
if (pcap_lookupnet(s, &net, &mask, errbuf) < 0)
{
fprintf(stderr,"Error in pcap_lookupnet: %s\n",errbuf);
}
else
{
printf("Preferred device is on network: %s/%s\n",iptos(net), iptos(mask));
}
exit(0);
}
void ifprint(pcap_if_t *d)
{
pcap_addr_t *a;
#ifdef INET6
char ntop_buf[INET6_ADDRSTRLEN];
#endif
printf("%s\n",d->name);
if (d->description)
printf("\tDescription: %s\n",d->description);
printf("\tLoopback: %s\n",(d->flags & PCAP_IF_LOOPBACK)?"yes":"no");
for(a=d->addresses;a;a=a->next) {
switch(a->addr->sa_family)
{
case AF_INET:
printf("\tAddress Family: AF_INET\n");
if (a->addr)
printf("\t\tAddress: %s\n",
inet_ntoa(((struct sockaddr_in *)(a->addr))->sin_addr));
if (a->netmask)
printf("\t\tNetmask: %s\n",
inet_ntoa(((struct sockaddr_in *)(a->netmask))->sin_addr));
if (a->broadaddr)
printf("\t\tBroadcast Address: %s\n",
inet_ntoa(((struct sockaddr_in *)(a->broadaddr))->sin_addr));
if (a->dstaddr)
printf("\t\tDestination Address: %s\n",
inet_ntoa(((struct sockaddr_in *)(a->dstaddr))->sin_addr));
break;
#ifdef INET6
case AF_INET6:
printf("\tAddress Family: AF_INET6\n");
if (a->addr)
printf("\t\tAddress: %s\n",
inet_ntop(AF_INET6,
((struct sockaddr_in6 *)(a->addr))->sin6_addr.s6_addr,
ntop_buf, sizeof ntop_buf));
if (a->netmask)
printf("\t\tNetmask: %s\n",
inet_ntop(AF_INET6,
((struct sockaddr_in6 *)(a->netmask))->sin6_addr.s6_addr,
ntop_buf, sizeof ntop_buf));
if (a->broadaddr)
printf("\t\tBroadcast Address: %s\n",
inet_ntop(AF_INET6,
((struct sockaddr_in6 *)(a->broadaddr))->sin6_addr.s6_addr,
ntop_buf, sizeof ntop_buf));
if (a->dstaddr)
printf("\t\tDestination Address: %s\n",
inet_ntop(AF_INET6,
((struct sockaddr_in6 *)(a->dstaddr))->sin6_addr.s6_addr,
ntop_buf, sizeof ntop_buf));
break;
#endif
default:
printf("\tAddress Family: Unknown (%d)\n", a->addr->sa_family);
break;
}
}
printf("\n");
}
/* From tcptraceroute */
#define IPTOSBUFFERS12
char *iptos(u_long in)
{
static char output[IPTOSBUFFERS][3*4+3+1];
static short which;
u_char *p;
p = (u_char *)∈
which = (which + 1 == IPTOSBUFFERS ? 0 : which + 1);
sprintf(output[which], "%d.%d.%d.%d", p[0], p[1], p[2], p[3]);
return output[which];
}
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap filter for 802.11
On Apr 16, 2004, at 3:01 AM, Chen Hsia Lee wrote: I have just started using libpcap and am still unfamiliar with it. What is the filter expression to pick up only wireless 802.11 packets? If you're capturing on an 802.11 interface, by definition all the packets you will get are wireless 802.11 packets. If you're capturing on some other type of interface, by definition *none* of the packets you will get are wireless 802.11 packets. As such, there's no filter expression to pick up only wireless 802.11 packets - if you want that, capture on an 802.11 interface. Do you mean, for example, "what is the filter expression to pick up only 802.11 *management* packets?" If so, then you have to construct a filter that looks at the 802.11 header to figure out the packet type; there's no built-in filter expression for that. See the 802.11 spec, and the tcpdump man page section on filter expressions; you'd use one of the expr relop expr True if the relation holds, where relop is one of >, <, >=, <=, =, !=, and expr is an arithmetic expression com- posed of integer constants (expressed in standard C syn- tax), the normal binary operators [+, -, *, /, &, |], a length operator, and special packet data accessors. To access data inside the packet, use the following syntax: proto [ expr : size ] Proto is one of ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp or ip6, and indicates the protocol layer for the index operation. (ether, fddi, wlan, tr, ppp, slip and link all refer to the link layer.) Note that tcp, udp and other upper-layer proto- col types only apply to IPv4, not IPv6 (this will be fixed in the future). The byte offset, relative to the indicated protocol layer, is given by expr. Size is optional and indicates the number of bytes in the field of interest; it can be either one, two, or four, and defaults to one. The length operator, indicated by the keyword len, gives the length of the packet. For example, `ether[0] & 1 != 0' catches all multicast traffic. The expression `ip[0] & 0xf != 5' catches all IP packets with options. The expression `ip[6:2] & 0x1fff = 0' catches only unfragmented datagrams and frag zero of fragmented datagrams. This check is implicitly applied to the tcp and udp index operations. For instance, tcp[0] always means the first byte of the TCP header, and never means the first byte of an intervening fragment. Some offsets and field values may be expressed as names rather than as numeric values. The following protocol header field offsets are available: icmptype (ICMP type field), icmpcode (ICMP code field), and tcpflags (TCP flags field). The following ICMP type field values are available: icmp- echoreply, icmp-unreach, icmp-sourcequench, icmp-redi- rect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstam- preply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp- maskreply. The following TCP flags field values are available: tcp- fin, tcp-syn, tcp-rst, tcp-push, tcp-ack, tcp-urg. Primitives may be combined using: A parenthesized group of primitives and operators (paren- theses are special to the Shell and must be escaped). Negation (`!' or `not'). Concatenation (`&&' or `and'). Alternation (`||' or `or'). Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right. Note that explicit and tokens, not juxtaposition, are now required for concatenation. expressions to test that; you'd test the link-layer header, so "proto" would be "link" or "wlan" (they mean the same thing). Also, what is the option for tcpdump to print the 802.11 header? "-e", as is the case with all link-layer headers. Which field is used to determine that a packet is an 802.11 packet?
Re: [tcpdump-workers] Proposed new pcap format
On Tue, Apr 20, 2004 at 06:16:48PM -0700, Michael Richardson wrote: > Darren> btw, is it at all easily possible to get the 802.3 checksum > Darren> into captured data ? > > On some OSes you ask for that. Not on BSD AFAIK, yes, with PF_PACKET > on Linux. Some BSDs give it to you, at least for some interfaces, with no way of not getting it (OS X with the Apple 10/100/1000 interfaces, and I think at least some NetBSD drivers do). How do you ask for it on Linux? (Or are they like those BSDs in that regard?) > And with GbE encoding, ECC memory and parity protected L3 cache buses, > the PCI bus *is* the least reliable interface in a typical PC. I believe > that people who do TCP checksum offload have experienced this problem > already. "Everything old is new again." We had a similar problem with an EISA-bus network device at Network Appliance ages ago - we didn't turn UDP checksumming on by default, and that problem caused us to do so, and the checksum caught the problem. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Is pcap thread-safe?
On Fri, Apr 23, 2004 at 11:05:23AM +1000, Darren Reed wrote: > The only part that wasn't thread safe (last time I checked) > was pcap_compile(). On Linux 2.0[.x] kernels, opening and closing a device isn't thread-safe, either, as, if the device is opened in promiscuous mode, it's added to a global list of promiscuous devices, and is removed from that list when closed (promiscuous mode has to be turned off by libpcap in 2.0[.x] kernels); there's no locking done on the list, so there's a potential risk of one thread stepping on another's toes. However, with versions of libpcap built with PF_PACKET support (which most modern ones should be) and running on 2.2 or later kernels, that list isn't necessary and thus isn't modified. There are also global variables manipulated without locks on opens and closes on AIX (for loading the BPF driver), DAG cards (similar to Linux 2.0[.x], as libpcap has to shut down DAG cards), and on systems with DLPI (Solaris and HP-UX, for example), there are some static buffers used when reading packets, but libpcap doesn't use the stuff in those buffers, so it might still be thread-safe (but we should perhaps make them local to "pcap_read_dlpi()" anyway). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap filter for 802.11
On Sat, Apr 24, 2004 at 07:21:59PM +0530, Chen Hsia Lee wrote: > I tried to set the wireless card into monitor mode using: > iwconfig eth1 mode Monitor > The error it gave was: > Error for wireless request "Set Mode" (8B06): > SET failed on device eth1: Invalid argument The Aironet driver (the driver normally used on Linux for the Cisco cards; Cisco bought Aironet) doesn't, as far as I know, support the wireless extensions, and I think that's what "iwconfig" uses to configure monitor mode. > I also tried changing the Config file using > echo: "Mode=rfmon" > /proc/driver/ethN/Config > (from the ethereal FAQ) but it did not work. Some versions of the Linux Aironet driver support that; some other versions might require you to, instead, capture on "wifi1" to capture in monitor mode, or so I infer from http://www.kismetwireless.net/documentation.shtml It would be Really Wonderful if the Aironet drivers for Linux used the same wireless-extension stuff that at least some other wireless drivers do. It would be Even More Wonderful if *all* the 802.11 drivers in Linux worked the same way when it came to turning on monitor mode, supplying 802.11 rather than Ethernet headers, etc. (and probably still *more* wonderful if *all* the 802.11 control stuff worked the same with all drivers). (It would also be Really Wonderful if all the 802.11 drivers in FreeBSD and NetBSD supported the new 802.11 ioctl stuff and BPF stuff in FreeBSD 5.2 and NetBSD-current, and if the remaining BSDs picked that up.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: Fw: [tcpdump-workers] Problems with fnct pcap_lookupdev()
On Wed, Apr 28, 2004 at 04:22:38PM +0200, César Cárdenas wrote: > It works now!!! Note that newer versions of libpcap/WinPcap have "pcap_findalldevs()", which returns information about all interfaces libpcap/WinPcap knows about and can open; the interface names are always in ASCII. > ps by the way, where I can see the list messages...I did not found in the > www.tcpdump.org page. There's a "mailing list" link on the main tcpdump.org Web page; following that link takes you to the mailing lists section of that page, which has a "This is archived here" link for tcpdump-workers, which takes you to http://www.tcpdump.org/lists/workers/ (yes, there are archives for all months in 2004; those are placeholders so that the page doesn't have to be changed every month). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IGRP
On Apr 28, 2004, at 7:03 PM, Michael Richardson wrote:
Hannes,
ipproto.c has IPPROTO_IGRP, but ipproto.h doens't define it.
Is this supposed to be protocol=9 ("IGP"), which you have as
IPPROTO_PIGP, or???
Actually, I made it IPPROTO_PIGP, not Hannes - that one's not his fault.
We used to have IPPROTO_IGMP as 9 and IPPROTO_EIGRP as 88; however,
some BSDs have IPPROTO_PIGP as 9 and IPPROTO_IGRP as 88, and don't have
IPPROTO_EIGRP at all, so IPPROTO_IGRP and IPPROTO_EIGRP both end up
defined as 88, and print-ip.c doesn't compile because it has two "case"
clauses with a value of 88.
I decided to have IPPROTO_PIGP be 9 and IPPROTO_EIGRP as 88, as the
current IANA protocol number assignments page says 9 is "any private
interior gateway (used by Cisco for their IGRP)" and 88 is "EIGRP" from
Cisco; so 9 isn't *explicitly* IGRP but 88 *is* explicitly EIGRP (not
IGRP).
That fixed the compilation problem on OS X 10.3.3 (which is one of the
BSDs in question), but ipproto.c continued to compile because OS X
(like the other BSDs) defines IPPROTO_IGRP (as 88) - but it fails on
OSes that don't define IPPROTO_IGRP.
The "temporary patch" Michael checked in is, in fact, the correct fix.
That raises another question, though - "print-ip.c" now treats both
protocol 9 and protocol 88 as IGRP, but the packet formats are, I
think, different - should we *only* treat IPPROTO_PIGP as IGRP, and
handle IPPROTO_EIGRP either not at all or with an "eigrp_print()"
routine?
(BTW, I'm sending this to [EMAIL PROTECTED] - if it
doesn't make it to the list, that might be because of the check for
headers that are too long, as I'm mailing it from work. I had to
shuffle the addresses around, as the reply-to address is still
[EMAIL PROTECTED] - perhaps that no longer bounces,
but it's bounced in the past.
I'm CCing Michael as well as Hannes on this; Michael, if this doesn't
make it to the list, you might want to configure the mail software
either to have a higher limit on the number of headers or not to count
"Received:" headers against the quota.)
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IPv6 dependency
On Apr 29, 2004, at 11:00 AM, Michael Richardson wrote: Your patch means that one can not decode v6 packets in a v4-only environment. I think that's already the case. We have strived to provide replacement headers whenever possible such that the dissectors are fully features on all platforms. There's a bunch of IPv6 stuff that's inside "#ifdef INET6" and that's compiled in only if --enable-ipv6 is specified. As I remember, that configuration switch doesn't work if you don't have IPv6 support on your platform. I started looking at trying to make the IPv6 stuff work (with some limitations, e.g. no address-to-name resolution for IPv6 addresses) on an IPv4-only system, but I haven't finished that. It's been a while since I looked at it, but I *think* the problem is that we rely on the underlying OS to define "struct in6_addr". - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IPv6 dependency
On Apr 29, 2004, at 4:05 PM, Michael Richardson wrote: Okay, it has been years since I was on a v6-crippled system, so I didn't know that we weren't OS independant. Can we extract some in6_addr code from one of the BSDs and include that if we need it? That might work - one concern would be a collision on OSes that *do* define it, but we could either 1) check in the configure script whether it's defined by the OS and define it ourselves if not or 2) have our own structure for v6 addresses (that's what Ethereal does). 1) is a bit easier, and doesn't involve a large pile of changes to the code, so I'd be inclined to go that route if we can. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap1.0
On Sun, May 16, 2004 at 06:26:40PM -0400, Michael Richardson wrote: > LINKTYPE enumeration. - metadata about linktype in file. > MUST put a meta-data packet about a particular link type before you > use that LINKTYPE. > > - - string saying name. Is the name one thing assigned to it when a new link-layer type is registered? Or is it purely intended for human use, so that the name can be different in different captures of the same type? > - - offset to IP header? What if it's variable? > - - framing type. (SNAP) What if it's variable? (For example: link layers with 802.2 headers might use the DSAP to indicate OSI traffic and a SNAP header for IP traffic - or might even use the DSAP for IP traffic, although I don't know whether anybody does that in practice; IPX has either 3 or 4 different ways it's encapsulated on Ethernet; ATM - what if you have both "classical IP" and LANE traffic?) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_stats
On Wed, May 19, 2004 at 03:54:48PM -0400, [EMAIL PROTECTED] wrote: > I recently compiled snort 2.1.3rc1 with libpcap 0.8.3 on Solaris 8 which > uses libpcap to report statistics among other things. > Before that I was running snort 2.1.1 with libpcap 0.7.2. > Whereas before I used to see 0% packets dropped as reported by Snort and > be happy, new version of snort suddenly was reporting about 15-20% of > packets dropped on average, once spiking to 128% (don't know how that's > possible). You'd have to check the Snort code to see how the packet drop value is computed. If it uses the value from "pcap_stats()", the problem might be that "ps_recv" counts packets seen but *not* packets dropped on DLPI systems - "pcap_stats()" is a bit broken, as it can only supply "packets received" and "packets dropped" values without distinguishing between "packets received" meaning "packets that were handed to the filter mechanism, even if they didn't pass the filter or passed the filter but were then dropped because there wasn't any buffer space" (as is the case with BPF), or "packets that were handed up to userland and thus obviously weren't dropped" (as is the case with DLPI), or "packets that passed the filter mechanism regardless of whether they were dropped or not" (as is the case with more recent Linuxes), or The DLPI code should *probably* add the dropped-packet count to the packets-received count, so as to reduce the differences between statistics (although it doesn't eliminate them - the right long-term fix is probably to introduce a new API that returns a set of tagged statistics values, so that if a given statistic can't be gotten from the packet capture mechanism it's not supplied by the API, so applications know what information they're getting). > Trying to figure it out, i recompiled 2.1.1 with libpcap 0.8.3 > and started seeing the same horrible performance. Compiling 2.1.3rc1 with > libpcap 0.7.2 reports 0% dropped. > > I am running this on a dual processor Ultra-2 with 1024MB of memory and a > qfe card. Most traffic i am seeing on an interface is 5Mbps, average > about 3.5 and I didn't think this would be an issue. > > My question: Which version of libpcap is lying to me? I looked through > the tcpdump mailing list, read some things, did some digging. It looks > like there were some changes in gathering/reporting the dropped packets: > > ../libpcap-0.8.3/pcap-dlpi.c: p->md.stat.ps_drop = > sbp->sbh_drops; > ../libpcap-0.7.2/pcap-dlpi.c: p->md.stat.ps_drop += > sbp->sbh_drops; There were more changes than that: revision 1.83 date: 2003/02/04 05:42:03; author: guy; state: Exp; lines: +23 -16 As per suggestions from the anonymous SourceForge user who submitted bug 673958, make two changes on Solaris: don't set SB_NO_DROPS - doing so means that bufmod doesn't drop packets, so it can't report the number of drops, but packets probably still get dropped *somewhere*, if for no other reason than that the system refuses to allocate more mblks/dblks, even if it doesn't discard messages that arrive at the stream head if it's full; set the chunk size to 65536, as otherwise packets are dropped too easily. snoop also appears not to set SB_NO_DROPS and also appears to set the chunk size to 65536, so that's probably the right thing to do. That change doesn't appear to be in 0.7.2 (which has version 1.74.2.3 of pcap-dlpi.c, at least according to the CVS log, and that version doesn't have that change in it), and one side-effect of that change is to change the DLPI version of libpcap so that it can return dropped packet counts other than zero. I.e., 0.7.2 probably wouldn't report *any* packet drops, so it'd be the one lying to you. Is Snort doing any capture filtering? I.e., does it call "pcap_setfilter()" with a non-trivial filter? If so, note that, on systems using DLPI, capture filtering is done in userland, so *every* packet received will be copied from the Solaris kernel to libpcap rather than packets that don't match the filter being discarded without being copied to userland. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_stats
On Fri, May 21, 2004 at 02:06:57AM -0700, Guy Harris wrote: > The DLPI code should *probably* add the dropped-packet count to the > packets-received count, so as to reduce the differences between > statistics (although it doesn't eliminate them - the right long-term fix > is probably to introduce a new API that returns a set of tagged > statistics values, so that if a given statistic can't be gotten from the > packet capture mechanism it's not supplied by the API, so applications > know what information they're getting). I've checked into the main and 0.8 branches of the libpcap CVS tree a change to do that. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_stats
On May 21, 2004, at 7:26 AM, [EMAIL PROTECTED] wrote: The way I see it in snort's implementation of the statistics it's doing ps_drop/(ps_recv + ps_drop). So I believe that part is accurate. As far as I can tell, that'd be *wrong* on BSDs and Linux 2.4 and later. The BPF in the BSDs I've looked at keeps a count of packets handed to "bpf_tap()" and "bpf_mtap()"; both of those call "bpf_filter()" to see whether the packet in question should be discarded and, if not, call "catchpacket()" to attempt to provide the packet to userland. If that attempt fails because there's no buffer space for the packet, the count of dropped packets is incremented. This means that all packets counted as dropped are also counted as received, so using "ps_recv + ps_drop" as the denominator counts dropped packets twice in the denominator. A comment I put into "pcap-linux.c" says * In "linux/net/packet/af_packet.c", at least in the * 2.4.9 kernel, "tp_packets" is incremented for every * packet that passes the packet filter *and* is * successfully queued on the socket; "tp_drops" is * incremented for every packet dropped because there's * not enough free space in the socket buffer. * * When the statistics are returned for a PACKET_STATISTICS * "getsockopt()" call, "tp_drops" is added to "tp_packets", * so that "tp_packets" counts all packets handed to * the PF_PACKET socket, including packets dropped because * there wasn't room on the socket buffer - but not * including packets that didn't pass the filter. so, in the statistics returned if the PACKET_STATISTICS socket option is supported on PF_PACKET sockets (which I think first officially appeared in 2.4, although Alexey Kuznetzov's turbopacket patches, which were, I think, incorporated in 2.4, might work the same way), the count of packets received also includes dropped packets. You might want to pass that on to the Snort developers. (Well, actually, it appears you already said that in http://marc.theaimsgroup.com/?l=snort-users&m=108508394000910&w=2 "In Linux it seems ps_recv already contains the number dropped, so adding ps_drop to them could increase the counter." Note, though, that with my recent libpcap changes, it should also make "ps_recv" contain the number dropped on Solaris as well, so with current-CVS main-branch or 0.8-branch libpcap using "ps_recv+ps_drop" as the denominator will also be wrong on Solaris.) However, that doesn't explain how the heck a percentage >100 can possibly be reported, unless "ps_recv" is (as someone noted in the original snort-users thread) is negative. I did some tests last night and this morning with two versions of snort, one compiled with libpcap 0.7.2 and the other with libpcap 0.8.3. I injected 1,000,000 packets to both of them over a cross-over cable. Snort with 0.7.2 reported capturing roughly 970k out of 970k packets, meaning it was definitely dropping packets, just didn't know about it. So it sounds as if the packets are, indeed, being dropped somewhere in the STREAMS stack for the DLPI connection other than in "bufmod", so that "bufmod" can't report the drops... Snort with libpcap 0.8.3 reported more accurate statistics, ...and 0.8.3 causes the same dropping to happen in "bufmod" (rather than, say, at the stream head, dropping packets because the queue is full, rather than "bufmod" checking whether it can queue stuff up above it and dropping the packet, and counting it, if it can't), so that the dropped packets are counted... and consistenly dropped less packets. ...and the other changes reduced the number of packets being dropped (as I think the person who submitted the SourceForge libpcap bug in question said they would). BTW, on the RH vs. FreeBSD drop issue in that thread: http://marc.theaimsgroup.com/?l=snort-users&m=108503075830508&w=2 http://marc.theaimsgroup.com/?l=snort-users&m=108507260320540&w=2 I'm a little skeptical of that being a libpcap 0.7[.x] vs. 0.8[.x] issue, as I don't remember doing anything to pcap-bpf.c that would cause such a problem (the code path might be a little longer on *all* platforms with the calls through function pointers in the pcap_t, but I wouldn't expect that to make a significant difference) - there shouldn't be much of *any* difference in the packet drop reporting. Now, perhaps the libpcap being used on Red Hat wasn't reporting drops, either because the RH-based sensors were running a kernel that didn't report drops to libpcap or because an older version of libpcap that didn't get packet statistics from the kernel was being used. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Thread safe?
On May 17, 2004, at 11:31 AM, Lance Uyehara wrote: Is there a thread safe version of libpcap around? I have pcap programs which include hostnames, i.e "dst host blahblah.com" and if multiple pcap programs fail to resolve the hostname then I sometimes get a core. I've looked at the source and I believe the problem is there are so many static variables in libpcap that it really does not work multi-threaded. The compiler *definitely* doesn't work multi-threaded; are you implying that you have multiple threads doing "pcap_compile()"? I don't know of any thread-safe version of "pcap_compile()". Unless compilation of filter expressions into BPF programs is done so often in your application that not multi-threading compilation would be a performance bottleneck, you might want to have a thread that does all the compilation - all of the other calls that take a "pcap_t *" as an argument, other than, perhaps, "pcap_close()" on some platforms, work in a multi-threaded program. (No guarantees about "pcap_open_live()", as it might add information to lists that aren't protected by mutexes - and "pcap_close()" would, in that case, use the lists as well.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] single packet capture time w/pcap vs. recvfrom()
On May 23, 2004, at 6:37 PM, Brandon Stafford wrote: I'm writing a server that captures UDP packets and, after some manipulation, sends the data out the serial port. Right now, I'm using recvfrom(), but it takes 20 ms to execute for each packet captured. I know that tcpdump can capture packets much faster than 20 ms/packet on the same computer, so I know recvfrom() is running into trouble, probably because of bad checksums on the packets. Is it a good idea to rewrite the server using pcap, It depends on the purpose of the server. If a received packet has a bad IP header or UDP checksum, it should get discarded at the IP or UDP layer, so that your application would *never* see it, not just see it after 20ms. If something out there causes the sender of the packet to retransmit it because it received no acknowledgments (because it was discarded by the IP or UDP layer, and thus not presented to a layer that would acknowledge it), with that happening after 20ms, then, if you use libpcap to read the packets, you'll see the initial bad packet *and* the retransmission. If that's what you want - i.e., if the server is supposed to log all the UDP packets in question, even if they have a checksum error - then it should use libpcap. However, if, in a case where a packet is retransmitted due to an error such as that, the server is supposed to log only the *valid* packet, then it's not clear using libpcap would provide any advantages. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] savefile.c patch
On May 26, 2004, at 1:55 AM, Gisle Vanem wrote:
I feel it's high time we cleanup some of the sources. I'd start
with savefile.c. Currently it doesn't work for offline data from stdin.
--gv
--- libpcap-2004.05.20/savefile.c Tue Mar 23 21:18:08 2004
+++ savefile.c Wed Mar 24 16:29:06 2004
@@ -52,6 +52,12 @@
#define TCPDUMP_MAGIC 0xa1b2c3d4
#define PATCHED_TCPDUMP_MAGIC 0xa1b2cd34
+#if defined(WIN32) || defined(MSDOS)
+#define SETMODE(file,mode) setmode(file,mode)
+#else
+#define SETMODE(file,mode) ((void)0)
+#endif
+
Perhaps it should just define "SETMODE()" as nothing - that would cause
SETMODE(file, mode);
to expand to
;
which, as a null statement, should be a valid statement.
Also, is "setmode()" sufficient with all the compilers that could be
used to compile libpcap/WinPcap on Windows (MSVC++, MinGW, etc.), or is
"_setmode()" needed with some compilers? (The code currently uses
"_setmode()".)
-#ifndef WIN32
- fp = fopen(fname, "r");
-#else
fp = fopen(fname, "rb");
-#endif
Presumably there are no interesting UN*X platforms left that wouldn't
ignore the "b" (Ethereal's library for reading capture files
unconditionally uses "rb"), so that should be OK.
- if(fp)
+ if(fp && fp != stdin)
fclose(fp);
+ if (fp == stdin)
+ SETMODE (fileno(stdin),O_TEXT);
Why not just
if (fp) {
if (fp == stdin)
SETMODE(fileno(stdin), O_TEXT);
else
fclose(fp);
}
@@ -973,6 +981,7 @@
pcap_dump_open(pcap_t *p, const char *fname)
{
FILE *f;
+ pcap_dumper_t *pd;
int linktype;
linktype = dlt_to_linktype(p->linktype);
@@ -985,26 +994,23 @@
if (fname[0] == '-' && fname[1] == '\0') {
f = stdout;
-#ifdef WIN32
- _setmode(_fileno(f), _O_BINARY);
-#endif
+ SETMODE(fileno(f), O_BINARY);
} else {
-#ifndef WIN32
- f = fopen(fname, "w");
-#else
f = fopen(fname, "wb");
-#endif
- if (f == NULL) {
+ setbuf(f, NULL);/* XXX - why? */
+ }
I'm not sure why we're setting the output unbuffered on Windows; even
if there's a legitimate reason to do so, I don't see any reason to do
so on UN*X - we really don't want to have the standard I/O library
routines make a separate "write()" call for every "fwrite()" etc. call
to the file.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Minor error in print-ipx.c
On May 26, 2004, at 3:24 AM, [EMAIL PROTECTED] wrote: gcc, at least on my FreeBSD 4.9 box, doesn't like an active statement before the first declaration (compiling tcpdump-2004.05.20): ./print-ipx.c: In function `ipx_print': ./print-ipx.c:60: syntax error before `const' I fixed it as shown below. Checked in. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] savefile.c patch
On May 26, 2004, at 2:16 PM, Gisle Vanem wrote: I wasn't sure why either. Maybe reducing the chance of a file with truncated packets. I just moved setbuf() further up. Actually, you moved the "if (f == NULL)" check down, leaving the "setbuf()" where it was, and also removed the "#ifdef WIN32"/"#endif" around the "setbuf()". That means the "setbuf()" will be done on UN*X as well - and also means that it'll try to do the "setbuf()" even if the "fopen()" fails, which will probably crash the program when it tries to dereference a null pointer. Also, that means that if it's writing to the standard output it won't do a "setbuf()" even on Windows. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] savefile.c patch
On May 26, 2004, at 2:35 PM, Guy Harris wrote: Also, that means that if it's writing to the standard output it won't do a "setbuf()" even on Windows. ...which, of course, it isn't doing now, either - but now writing to the standard output won't work right on Windows as it's writing in text mode. Also, should we save the mode returned by "setmode()" and restore it when we close a "pcap_t" or "pcap_dumper_t" that refers to the standard input or output? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Facing a problem when I try to capture NetBeui packet (NBF) of ether frames
On Thu, May 27, 2004 at 02:38:57PM +0800, Bassam A. Al-Khaffaf wrote: > But for other ether frame protocols such as arp, rarp and ip there is no > problem and they work. Try just tcpdump netbeui "ether proto" expects a protocol with an Ethernet type value - but NetBEUI doesn't have an Ethernet type value (it runs atop 802.2, not atop raw Ethernet, so the NetBEUI frames don't have an Ethernet type field, they have a length field). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Various diffs for more complete LDP decoding
On May 27, 2004, at 11:04 AM, [EMAIL PROTECTED] wrote:
Below are patches to perform significantly more complete LDP decoding.
Checked in, with an unused variable removed, and with declarations of
"decode_prefix{4,6}()" put into a "decode_prefix.h" header included by
"print-bgp.c" and "print-ldp.c".
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] savefile.c patch
On May 27, 2004, at 5:22 AM, Gisle Vanem wrote: Since pcap_dump_close() doesn't have a pcap_t argument, where should the oldmode come from? Can we have two module globals; oldmode_stdin, oldmode_stdout, assuming stdin/stdout won't be opened for capture more than once? If it's opened for capture or dumping more than once in sequence, that's not an issue; if it's opened for capture or dumping more than once in parallel, that's not going to work anyway. As such, the two globals would probably be the best idea. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] How to extract the source name field data of
On May 27, 2004, at 11:56 PM, Jun-ichiro itojun Hagino wrote: Yes I am doing live capturing, but all what I interested about is the 16 byte "Source Name" field (Name to Add). I want to include the tcpdump command in my perl program so that I can make further processing on the data of that field. i would suggest you write a program using libpcap.a, rather than try to play with tcpdump output. Or that he modify an existing program using libpcap, namely tcpdump, to understand more NBF command types (such as ADD_NAME_QUERY, which his packet appears to be), and then send us the patches so we can add that to a future release. The code is in "netbeui_print()" in "print-smb.c"; the "smb_fdata()" routine isn't documented, but it should be possible to figure out how the format strings work (the items in square brackets describe how to format the current field in the packet). The NBF packet formats are at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/BK8P7001/ CCONTENTS tcpdump has to be run with "-vv" to get it to print the details of NBF packets. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] How to extract the source name field data of
On Fri, May 28, 2004 at 11:55:53AM -0700, Guy Harris wrote: > Or that he modify an existing program using libpcap, namely tcpdump, to > understand more NBF command types (such as ADD_NAME_QUERY, which his > packet appears to be), and then send us the patches so we can add that > to a future release. Or that he run the current CVS version of tcpdump (which should show up as "current tar files" on the tcpdump.org site in the next couple of days), which understands more command types, including ADD_NAME_QUERY... > tcpdump has to be run with "-vv" to get it to print the details of NBF > packets. ...and shows a summary of the packet even without "-v". - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcab and libpcap differences?
On Mon, May 31, 2004 at 03:45:04PM +0800, Bassam A. Al-Khaffaf wrote: > As introduction for me to learn the network programming, anyone can tell me > what is the difference between the "pcap" and "libpcap"? THe letters "l", "i", and "b". :-) The name of the library is "libpcap"; sometimes people might just call it "pcap", but they're just two names for the same thing. People might also refer to the capture file format produced by, and read by, libpcap as "libpcap" or "pcap" format; again, they're the same file format. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump"
On Jun 4, 2004, at 9:32 AM, ice ice wrote: Yes, I should say that the trace file is in pcap format. 20020814-09-0-anon.pcap.gz: tcpdump capture file (little-endian) - version 2.4 (BSD/OS Cisco HDLC, capture length 48) So I couldn't assume the 48byte header is the normal IP+whatever header even it says Cisco HDLC? It's not a "48byte header", it's a 48 byte capture length. However, 48 is a very suspicious number here, given that the CoralReef stuff is ATM-oriented, although I'd expect it to be 53, not 48, if the packets in that capture are ATM cells - it'd probably be pretty silly to supply the cell payload but not the header. But, no, the header of those packets isn't necessarily just a "normal IP+whatever header". For one thing, there's no guarantee that the packets are IP packets, and, for another thing, there's header information *before* the IP header, namely the link-layer header, and the link-layer header is what would specify whether the packets are IP packets or not. The header of packets isn't necessarily just a normal "IP+whatever header" even with an *Ethernet* (DLT_EN10MB) capture, for the same reasons. If they're *truly* Cisco HDLC packets - and, if tcpdump can read that capture file, it'd treat it as Cisco HDLC, so it sounds as if they are - the packet format is described in http://www.nethelp.no/net/cisco-hdlc.txt (and see also section 4.3.1 of RFC 1547); the packet starts with a four-byte link-layer header with one byte of address, one zero byte, and two bytes containing a protocol type. The protocol types are usually Ethernet protocol types, so 0x0800 would be IP, but Cisco added some additional packet types (see the URL given above). *IF* the protocol type is 0x0800, after the 4-byte header comes an IP header and IP payload. All of this is the case *IF* the link-layer type is DLT_C_HDLC (or DLT_CHDLC on some versions of libpcap, but they have the same numerical value). If you're using libpcap to read a capture file, you have to call "pcap_datalink()" to get the link-layer header type for the capture, and interpret the raw packet data based on that - that's what tcpdump does. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump"
On Jun 4, 2004, at 1:09 PM, ice ice wrote:
here is more information about tcpdump's output:
% tcpdump -c 5 -n tcp -r 20020814-09-0-anon.pcap.gz
11:00:00.58 69.245.49.10.2082 > 143.173.237.247.1214: .
2133229289:2133230749(1460) ack 6821225 win 17188 (DF)
11:00:00.69 236.179.225.218.47302 > 241.46.188.127.www: . ack
3266262189 win 17520 (DF)
11:00:00.83 3.3.241.136.10646 > 252.224.52.109.1469: P
1396830536:1396830556(20) ack 446314422 win 9660 (DF)
11:00:00.97 3.3.241.136.10646 > 252.224.52.109.1469: .
4294965916:0(1380) ack 1 win 9660 (DF)
11:00:00.000102 3.3.241.136.10646 > 252.224.52.109.1469: .
4294964825:4294965916(1091) ack 1 win 9660 (DF)
these output seems ok to me,
so can I assume that the tcpdump can recognize the trace correctly?
It appears so. I.e., it probably really *is* a Cisco HDLC capture.
If so, that means the 48 byte is a correct number?
It means that the snapshot length being equal to the payload length of
an ATM cell does not imply that the capture is an ATM capture; I have
no idea why the snapshot length was 48, though - perhaps that's what
the DAG card supplied.
It does *NOT* mean that every packet is 48 bytes long, however.
So I guess I can just cast the following 40 bytes into what ever
(TCP/UDP...) header it indicates.
What "following 40 bytes"?
The packets will have:
1) a 4-byte link-layer header;
2) some number of bytes of payload.
The total number of bytes, *including* the 4-byte link-layer header, is
the "caplen" value from the "pcap_pkthdr" supplied to the callback
routine for "pcap_dispatch()" or "pcap_loop()" or "pcap_next()" or
"pcap_next_ex()" ("pcap_next_ex()" is available only in libpcap 0.8 and
later). If that value is > 4, then the number of bytes of payload is
that value minus 4.
If the last two bytes of the 4-byte link-layer header, when treated as
a big-endian number (i.e., don't just fetch it as a 2-byte integer -
you'll get the wrong value on a little-endian machine, and note that
x86-based PC's are little-endian machines) is equal to 0x0800, then the
payload begins with an IP header. As the snapshot length is > 24, the
snapshot length will preserve the fixed-length portion of the IP
header, but note that if there are IP options, the header could be
larger than 20 bytes. Note also that there might be something *other*
than the snapshot length that caused the entire header not to be
present, so you should really check the "caplen" value.
If it's present in the header (i.e., "caplen" is large enough to say
it's there), use the protocol number field from the IP header to
determine what type of header the IP payload begins with. Use the
"header length" field of the IP header to determine where the IP
payload begins; do *NOT* assume that the IP header is 20 bytes long.
(If the header length is *less* than 20 bytes long, that's an error;
you should check for that.)
Also, note that the IP header has a "total length" field. The length
of the IP payload is that value minus the IP header length - but if
that value is greater than "caplen" minus (4 + IP header length), use
"caplen" minus (4 + IP header length) instead.
btw, to my understanding that I can not change tcpdump's output format,
You can't do it without changing tcpdump - but you might want to use
tcpdump as the basis for your program, as all the stuff I describe
above, including handling multiple types of link-layer header, is
already done by tcpdump, so you don't have to reinvent the wheel (or
reinvent the flat tire by just crudely casting the packet data to an
IP+TCP headeer or something such as that).
I am currently reading the source code of tcpdump and try to figure
out the way to
parse through the packets. I am wondering whether there is some simple
sample programs
I can read or use in analyzing the pacekts?
There's a limit to how "simple" a correct program can be; a correct
program has to worry about the stuff I described above - there might be
simple sample programs out there, but they might do something incorrect
such as assuming the packet starts with a 14-byte Ethernet header (true
only if the link-layer type of the capture is DLT_EN10MB), or that
after the link-layer header is a 20-byte IP header (true only if the
link-layer header says it's an IPv4 packet *AND* the IP header length
is 20 bytes) or that after the IP header is a 20-byte TCP header (true
only if the IP header says it's a TCP packet *AND* there are no TCP
options).
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Linktype needed
Martin Angler said: > my name is Martin Angler and I am developing a BACnet MS/TP - enabled netdevice-driver > under GNU/Debian Linux. Now I've seen, that there is no linktype that specifies BACnet > MS/TP. So I wanted to ask whether you could define/implement a corresponding linktype. I infer from some stuff I've seen that BACnet MS/TP is a link-layer protocol atop which the higher-level BACnet protocols can run (just as they can run atop UDP and 802.2). Will your driver supply "raw" packets with a header specified by the BACnet specification (the ISO standard appears to cost over 350 CHF, so I haven't bought it), or will it supply some form of "cooked" software that might not be what other BACnet MS/TP capture mechanisms might supply? If the former, the linktype should probably be called DLT_BACNET_MS_TP or something such as that; if the latter, the name should probably have something in it to indicate what type of header it is (see, for example, DLT_ARCNET, which should perhaps have been DLT_ARCNET_BSD, and DLT_ARCNET_LINUX, or DLT_APPLE_IP_OVER_IEEE1394, which is not raw Firewire but has a synthetic header). > Other people that worked on an MS/TP dissector (www.abmlinux.de) already tried to > contact you, but without success. I don't think I've seen that on tcpdump-workers. Do they have their own driver and, if so, does it supply the same link-layer header (if not, it'd need a separate DLT_ value)? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Linktype needed
On Jun 7, 2004, at 3:28 AM, Martin Angler wrote: Yes, our driver will supply "raw" packets with the header specified by the BACnet specification. Therefore we would appreciate your first suggestion, which would be naming the linktype DLT_BACNET_MS_TP. OK, I've added DLT_BACNET_MS_TP, with the value 165. There's currently no code in libpcap to capture on devices of that sort; you'd have to supply that code to work with your driver. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Unexpected primitive ack DL_UNITDATA_IND
On Jun 9, 2004, at 1:27 PM, Rick Jones wrote: Does it always happen or just sometimes? A DL_UNITDATA_IND is basically saying "Hi there, here is a packet" in DLPI speak. It looks like the stream is sending one of those up to the application when libpcap isn't expecting it. In fact, it's sending one up when, presumably, libpcap is waiting for a DL_INFO_ACK in response to a DL_INFO_REQ it sent downstream to determine either the DLPI provider style or the link-layer type. I don't have the DLPI spec handy; currently, pcap-dlpi.c makes two info requests, one just after opening the device and one after binding to the PPA (but *before* setting DLIOCRAW or pushing "bufmod") - can a DLPI provider cough up packets at that point? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Unexpected primitive ack DL_UNITDATA_IND
On Jun 9, 2004, at 1:58 PM, Rick Jones wrote: On the surface I wouldn't think so - simply attaching to a PPA I don't think means traffic could arrive - however, if one has attached, and then binds to a SAP, then traffic could indeed start arriving. (Il-informed guesstimation, and hopefully I'm recalling the correct distinction between attach and bind) Well, we *are* doing an info request after binding, so perhaps it might happen then. I'm not sure why we're doing that; it dates back to libpcap 0.4. Do you know of any reason why the "dl_mac_type" from an info request before binding to a SAP might be different from the "dl_mac_type" from a request after binding to a SAP? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Unexpected primitive ack DL_UNITDATA_IND
On Jun 9, 2004, at 2:55 PM, Rick Jones wrote:
Guy Harris wrote:
Well, we *are* doing an info request after binding, so perhaps it
might happen then.
I'm not sure why we're doing that; it dates back to libpcap 0.4. Do
you know of any reason why the "dl_mac_type" from an info request
before binding to a SAP might be different from the "dl_mac_type"
from a request after binding to a SAP?
I cannot think of one - of course, DLPI being what it is...
I'll experiment (time permitting) with getting rid of the second one on
Solaris 7 (that's what I have access to); any idea whether any of HP-UX
{9.x,10.x,11.x} would need the link-layer type to be fetched after the
bind?
I thought though that the SAP selected was rather, um, obscure?
Well, on Solaris it's just 0, with DL_PROMISC_SAP requested.
HP-UX 11.x is a bit weird, with INSAP (22) being used to receive and
OUTSAP (24) being used to send. It looks as if we use 0 *after*
requesting DL_PROMISC_SAP (in non-promiscuous mode) or DL_PROMISC_PHYS
(in promiscuous mode) on 9.x and 10.20.
AIX is a bit annoying - it looks as if you have to select *some* value
> 0x600 on standard Ethernet and 2 on Token Ring.
I suppose one thing to consider would be to have some sort of
bugcatcher in the code that displayed the entire contents of the
unexpected message - say simply in hex. Then one could determin if it
matches the bound SAP.
...except that we're trying to run in "SAP promiscuity" mode, so that
we should get packets from all SAPs.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Unexpected primitive ack DL_UNITDATA_IND
On Jun 11, 2004, at 9:03 AM, Gordon Tyler wrote: So, the rough summary of all this is that it was unlucky timing that libpcap received a packet which it wasn't expecting? The rough summary is that it's unlucky timing, but libpcap is *perhaps* doing something it doesn't need to do and, if it didn't do that, this might not happen. I haven't had time to look at the DLPI specifications in detail to see whether either of the assertions in the second clause of the previous sentence are correct; Rick Jones probably hasn't had time, either. Is there anything I can do protect my application from this? Not in your application. A change to libpcap *might* make it not happen, although it *might* also cause other problems; we haven't had time to construct such a change or to, for example, test it on Solaris (and even if it works on some version of Solaris, it might not work on other versions or on other OSes that use DLPI). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] timeout in linux
On Jun 14, 2004, at 7:11 AM, fcarone wrote: Hello! Im new in programming with libpcap and im using the libpcap0.8.3, and i´d like to know if the timeout works in linux RH9 kernel 2.4.20. No, it does not. The timeout is passed on to the underlying OS's packet capture mechanism, if it supports a timeout; Linux's PF_PACKET sockets don't. It works on Solaris - but *NOT* in the way people might expect it to work; in Solaris, the timer doesn't start until at least one packet is received, it does *NOT* start as soon as you try to read from the descriptor. The only platforms I know of on which the timer will go off even if *NO* packets have been received are: the BSDs (including Mac OS X); AIX, I think, *if* libpcap is using BPF (*NOT* if it's using DLPI); Digital UNIX, I think; Windows. Applications should *NOT* rely on the timeout if they want to keep from waiting forever for a packet to arrive, except on the platforms in question. If they want to, for example, multiplex input from libpcap and some other input source, they should use "select()" or "poll()" on UN*X and "WaitForMultipleEvents()" or "MsgWaitForMultipleEvents()" on Windows. To get from a "pcap_t *" a descriptor that can be used for "select()" or "poll()", use "pcap_get_selectable_fd()" if the version of libpcap you're using has it, otherwise use "pcap_fileno()". Note that "pcap_get_selectable_fd()" can return -1 if, for example, "select()" on the "pcap_fileno()" descriptor won't work; it won't work, for example, on some releases of FreeBSD. Note also that, in some releases of all of the BSDs, "select()" and "poll()" work on it, but not completely correctly. To quote the libpcap 0.8 man page: Note that on most versions of most BSDs (including Mac OS X) select() andpoll()donotworkcorrectlyonBPF devices; pcap_get_selectable_fd() will return a file descriptor on most of those versions (the exceptions being FreeBSD 4.3 and 4.4), a simple select() or poll() will not return even after a timeout specified in pcap_open_live() expires. To work around this, an application that uses select() or poll() to wait for packets to arrive must put the pcap_t in non-blocking mode, and must arrange that the select() or poll() have a timeout less than or equal to the timeout specified in pcap_open_live(), and must try to read packets after that timeout expires, regardless of whether select() or poll() indicated that the file descriptor for the pcap_t is ready to be read or not. (That workaround will not work in FreeBSD 4.3 and later; however, in FreeBSD 4.6 and later, select() and poll() work correctly on BPF devices, so the workaround isn't necessary, although it does no harm.) On Windows, use "pcap_getevent()" to get a HANDLE that should be usable with "WaitForMultipleEvents()" or "MsgWaitForMultipleEvents()", although note that on older versions of WinPcap (2.3 and before, I think, although this bug might have been fixed in 2.3, I don't remember), it does *not* return a valid HANDLE on Windows NT 4.0/2000/XP/2003 Server. I *think* that works in 3.0, on both Windows 95/98/Me and NT 4.0/2000/XP/2003 Server, but I haven't tested it. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump -tttt option and timezone
On Jun 14, 2004, at 1:38 AM, Raphael Raimbault wrote:
There is a patch for 3.8.3 version:
--- tcpdump.c.orig Sun Jun 13 15:50:49 2004
+++ tcpdump.c Sun Jun 13 16:05:34 2004
@@ -615,7 +615,7 @@
/* NOTREACHED */
}
- if (tflag > 0)
+ if ((tflag > 0) || (tflag == -3))
thiszone = gmt2local(0);
if (RFileName != NULL) {
Checked into the main and x.8 branches.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] setting rcvbuf
On Jun 15, 2004, at 2:49 PM, John Heffner wrote: I've found that on my linux machines, setting the rcvbuf on the packet socket bigger helps to reduce drops at high rates. I implemented the following, though I'm not sure how this works on BSD and other UNIXes. It *doesn't* work on BSD, unfortunately - you can't set the buffer size after binding a network interface to a BPF device, and, as that's done at open time, you can't set the buffer size on an open pcap_t. The ultimate fix is probably to have a new open routine that takes the buffer size as an argument (but don't implement that - there's a bunch of other stuff for which we need a new open API, and we don't want to introduce one new API and then keep introducing new ones; I'm thinking of an API that takes an attribute/value list of open parameters, so we can add new parameters as needed without having to introduce a whole new API). A short-term fix would be to implement "pcap_setbuff()" routines for all platforms - but have, on platforms where you can't set it, either no-op routines or routines that return an error - and, when we have the new open routine, deprecate "pcap_setbuff()" in favor of the new open routine. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap range no worky on ppc? (e.g. udp[2:2] >= 137 && udp[2:2] <= 139)
On Thu, Jun 17, 2004 at 03:19:40PM +1000, Ben Low wrote: > I attempted to use the following expression to filter netbios stuff: > > udp[2:2] >= 137 && udp[2:2] <= 139 > > However this expression only captures port 137 packets on my two Power > PC machines: > - linux 2.4.18 ppc (debian) > tcpdump version 3.8.3 / libpcap version 0.8.3 > - OS X 10.3.4 PowerBook (fink) > tcpdump version 3.8-cvs / libpcap version 0.8 > > It works as expected on an x86 linux box (tcpdump version 3.6.3 / > libpcap version 0.6). Is this a pcap 0.8, or PPC (endianness?) problem? It's a pcap 0.8 problem: https://sourceforge.net/tracker/index.php?func=detail&aid=940212&group_id=53067&atid=469577 There's no UDP port 139 NetBIOS-over-TCP stuff, so if you want NBT traffic, try udp port 137 or udp port 138 or tcp port 139 which shouldn't have a problem with that optimizer bug - and, for completeness, try udp port 137 or udp port 138 or tcp port 139 or tcp port 445 to catch CIFS-over-TCP (without the NBT layer). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] TCPDUMP filter for multicast
(I'm on tcpdump-workers, so there's no need to send mail to me *and* tcpdump-workers; if you have a question, it's better to ask tcpdump-workers than to ask only me.) On Sat, Jun 19, 2004 at 10:07:17PM -0400, Ernest L. Williams Jr. wrote: > Could you tell me a tcpdump filter that only gives multicast? > 'ether[0] & 1 != 0' gives both multicasts and broadcasts; I only want > multicasts. How about multicast and not broadcast - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] TCPDUMP filter for multicast
On Sat, Jun 19, 2004 at 10:35:54PM -0400, Ernest L. Williams Jr. wrote: > Do I have to join the list? Looks like there is a post block on me at > the moment. You might have to join the list in order to be able to mail to it. It's not very high-volume > However, I am only getting address starting with 224. > I would like to see my 239 guys as well. Try capturing with "ip net 239.0.0.0/8" - and see what the MAC addresses are for those packets. If they have multicast MAC addresses, "multicast and not broadcast" *should* capture them, so there might be a bug somewhere. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap, 802.11 and promiscuous mode
On Jun 21, 2004, at 3:39 AM, [EMAIL PROTECTED] wrote: I am working on a project that involves sniffing 802.11 traffic. I am using an Orinoco-based WLAN card. I read that libpcap are not suitable as they are to sniff 802.11. Libpcap 0.7 and later should be able to handle 802.11 on Linux *IF* the Linux driver supports it, and should be able to handle 802.11 on FreeBSD 4.6 or later with Aironet cards (but not Orinoco cards). Libpcap 0.8 and later should be able to handle 802.11 on Linux if the driver supports it, should be able to handle 802.11 on FreeBSD 4.6 or later with Aironet cards, and, I think, should be able to handle 802.11 on FreeBSD 5.2 or later, and NetBSD 2.0-BETA or later, with Prism II-based cards, Atheros cards, and *possibly* Orinoco-based cards. There might also be support on some versions of OpenBSD. According to what I found out, libpcap have to be patched to do that Only older versions do; see above. but the patch works only if the WLAN card is set in monitor mode. Is this true? It might be. it depends on what 802.11 traffic you want to capture. Some 802.11 cards (perhaps all of them) might supply only data packets - *NOT* management or control packets - if the card isn't in monitor mode. This is *NOT* something libpcap can do anything about; it's something the driver would have to do something about, *IF* the driver can even do *ANYTHING* about it (if it's a limitation of the card, there isn't even anything the driver can do about it). I don't know whether that's true of some cards, all cards, or no cards. I suspect that those cards that can run in "host AP" mode can, at least in theory, supply at least some management packets, as the host would need to see those packets in "host AP" mode. I don't, however, know 1) whether the Orinoco cards support "host AP" mode; 2) if they do, whether the Linux Orinoco driver or drivers support "host AP" mode, and whether any of the BSD "wi" drivers support "host AP" mode on Orinoco cards (as opposed to Prism II cards - the "wi" drivers handle both Orinoco and Prism II cards on the BSDs); 3) if they do, whether, when you're capturing traffic, they supply management packets to the application; 4) if they do, whether you get *all* management packets received by the card or just some of them; Is there a way to use libpcap libraries to sniff 802.11 packets keeping the wireless card in promiscuous mode? 5) whether they do that in promiscuous mode as well as non-promiscuous mode. Note also that, to run Orinoco cards in monitor mode, you'd need to patch older versions of the Linux driver: http://airsnort.shmoo.com/orinocoinfo.html and that some or all of the BSD "wi" drivers might not support monitor mode on Orinoco cards. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap problems
On Jun 22, 2004, at 8:45 AM, Bowser Jason S Contr AFRL/IFTA wrote: I am writing some software that forks multiple process on a unix macine(IRIX) however when i have each child start the pcap_loop when i get to the 4th child and beyond i get the following error pcap_open_live snoop bind: Cant assign requested address However if i comment out the pcap_loop line the i dont get that error. I am opening the device (ef0) using promiscous mode if that helps I.e., you have four processes doing a "pcap_open_live()" on "ef0" in promiscuous mode? You might want to ask SGI about this - perhaps there's a limit on the number of "snoop" sockets that can be bound to a particular network interface, although I have no idea why such a limit would show up only if you have a read in progress on the sockets. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Web page needs updating
On Jun 22, 2004, at 8:48 AM, Eddie Kohler wrote: The www.tcpdump.org section on mailing lists needs updating -- sending mail to '[EMAIL PROTECTED]' results in an error; it looks like the address has changed to '[EMAIL PROTECTED]'. I've checked in a change to replace "@tcpdump.org" with "@lists.tcpdump.org" - that'll presumably get propagated to the Web site at some point. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
