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íÆ
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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 ther
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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.m
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...@alu
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
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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
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...@alu
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Ø
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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-wor
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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.m
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.sand
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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.san
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.san
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 ther
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
The original message was included as attachment
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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.
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 ther
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 ther
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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.sa
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.sa
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.sa
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...@al
á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ª
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.sandel
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.m
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
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 agains
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
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_CI
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"
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 whi
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()" a
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
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
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
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 th
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 pa
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 suppli
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
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 th
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
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-
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 g
(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
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
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
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 t
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
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
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 st
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 prin
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 8
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 lea
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
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 Airon
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 wa
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 IPP
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.
T
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 coll
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
ersion 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_dro
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 prob
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
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 be
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 packe
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
@@ -
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.
C
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"/"#en
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
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 Et
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
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
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
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
>
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
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 ev
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.473
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 fro
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 val
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
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
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
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
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
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 ((tfla
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, unfortunatel
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)
> t
(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 multic
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 star
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
Li
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 ass
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.t
1 - 100 of 2513 matches
Mail list logo
