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
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
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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 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 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
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
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
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
á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°À¥
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
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
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
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
x¤Ç
tÛ¬.I[
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
___
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
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
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
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 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
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ð)ø
___
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
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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
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()
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
(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 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
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
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
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
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
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 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 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
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
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
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 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
(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
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
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
On Jun 25, 2004, at 2:21 PM, Christian Kreibich wrote:
an XML based tcpdump output would
be great in the long term -- it would certainly eliminate a lot of
parsing ambiguity.
Yes - the problem with the traditional UNIX the output of one program
should be usable as input to another program idea is
On Jun 25, 2004, at 4:34 PM, Xavier Brouckaert wrote:
Could it happen because there are several applications using libpcap
at the same time ?
Not if they're writing to different files. There's no data that would
be shared by all libpcap-using processes on a given machine.
If multiple
On Jun 28, 2004, at 1:21 PM, [EMAIL PROTECTED] wrote:
We would like to include WinPcap and WinDump on the Windows Toolbox
compilation of
software but your licencing restrictions present a problem. The clause
we have difficulty with in
particular is this:
all advertising materials mentioning
On Jun 28, 2004, at 12:10 PM, four wrote:
Here is the situation: I am trying to build a simple bridging program.
If I use pcap_set_nonblock() the function call returns fine, but the
program ends up using 100% cpu utilization, presumably because it is
simply looping and returning with no packets
On Jun 30, 2004, at 10:00 AM, Jefferson Ogata wrote:
More specifically, you can use libpcap as any user. On most systems,
you have to be root, however, to monitor traffic on a network
interface.
I.e., you can use libpcap to read a capture file as any user (if that
user has permission to read
On Jun 30, 2004, at 12:58 PM, Michael Richardson wrote:
How widespread is PDML?
Tethereal and Ethereal can generate it; I presume the intent is to have
Analyzer 3.0 generate it as well, given that it was invented by the
Politecnico di Torino folks. (I don't see anything immediately obvious
On Thu, Jul 01, 2004 at 07:34:44AM +0200, Fulvio Risso wrote:
Ethereal is able to prodice PDML output (altough it uses a slightly modified
dialectn of PDML).
What are the modifications? (Note that one problem is that PDML's field
names come from the NetPDL specification for the protocol - this
On Jul 1, 2004, at 2:50 AM, [EMAIL PROTECTED] wrote:
tcpdump doesn't have any specific facility to handle fragmented
packets,
as far as I know (it cannot reassemble the fragments).
That capability could be added (Ethereal supports it), although, if
provided, it should be an option (as reassembly
On Jul 1, 2004, at 12:18 PM, alex medvedev wrote:
this, however, does not work well with relative seq numbers in tcp
packets [maybe smth else too?].
Anything that maintains and uses state information between packets
wouldn't work.
However, what could be done would be something that still runs
On Jul 5, 2004, at 3:13 AM, Darren Reed wrote:
Looks better if its compressed PPP data :)
Checked in, with compressed PPP data - and with another change to use
ppptype2str[] in the default case.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Jul 5, 2004, at 4:51 AM, Darren Reed wrote:
If ppp_hdlc() is called with length 2, bad things happen.
Should it be called *at all* from handle_ppp()?
Or, if this is really just HDLC-over-L2TP, in which case it should be
called directly from t
On Jul 7, 2004, at 10:44 AM, Claudio Lavecchia wrote:
Writing a packet dissector based on pcap libraries on Linux and using
it to sniff traffic going through a WLAN (dell truemobile 1150 with
orinoco driver) card I noticed a really strange behaviour. The card is
set in promiscous mode, and I
On Thu, Jul 08, 2004 at 11:38:33AM +0200, rmkml wrote:
Possible add detect tcp header len pb in tcpdump ?
I've added those checks to the x.8 and main branches in the tcpdump CVS
tree.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Jul 13, 2004, at 7:56 AM, Klaus Schrod wrote:
Again our situation: Two computers connected to the net, one (lion)
with a fixed ip address and one (styx) with pppoe. We established an
ipsec tunnel between them successfully. tcpdump showed an error in the
ESP traffic between styx and lion. But
On Jul 13, 2004, at 11:51 AM, Guy Harris wrote:
whereas the traffic from 62.225.140.214 to 217.234.111.121 has
Linux cooked capture
IP with a protocol type of IP-inside-IP
IP (with a bogus version number of 3 and a bogus header length of 8)
The second capture is similar
On Jul 13, 2004, at 12:44 PM, César Cárdenas wrote:
It is possible to write raw packets in a *.txt file?
That depends on what you mean by raw packets.
Packet data is binary, so that wouldn't go into a .txt file.
The packet data can be dumped in hex and/or ASCII, and that could be
put into a text
On Jul 19, 2004, at 6:57 AM, Alex Narinsky wrote:
I need to change the filter condition dynamically. So I have another
thread that changes filter expression.
This code works fine on Windows changing the filter condition. On
LINUX
if I change a filter condition no packages come anymore through
On Jul 20, 2004, at 1:32 AM, Li Ruzhen wrote:
hi, whether i can use libpcap to optimize some
complicate expressions and then conver the optimized
result back to the expression format?
If by expressions you mean filter expressions, no, you can't -
there's no code that takes a BPF program (which is
On Jul 20, 2004, at 10:40 AM, [EMAIL PROTECTED] wrote:
gcc -O2 -I. -DHAVE_CONFIG_H -D_U_=__attribute__((unused))
-c ./gencode.c
In file included from gencode.c:73:
pf.h:66: syntax error before sa_family_t
Which version of libpcap is this? 0.8.3?
And what are the contents of the
I have some changes to support that.
The main change is to add a union h6addr to tcpdump-stdinc.h, along
with defintions of IN6_IS_ADDR_UNSPECIFIED, AF_INET6, and NI_MAXHOST if
they're not defined.
Some side-effects of this:
1) it defines DEFAULT_SNAPLEN as 96 unconditionally, rather
On Tue, Jul 20, 2004 at 03:25:03PM -0400, Michael Richardson wrote:
Guy == Guy Harris [EMAIL PROTECTED] writes:
Guy Michael, should we put out a libpcap 0.8.4/tcpdump 3.8.4
Guy release with the fixes that have been added since then?
I guess.
Are there other things that should
On Jul 22, 2004, at 1:47 PM, Aaron Mitchell wrote:
I've noticed a peculiar behavior. Given the same hand-crafted
dump file (with an intended time of 5:36 on Jan 1, 1970), tcpdump
reports a time of 6:36 for default output, and a time of 10:36 when
run with the - option (supposedly same time
On Jul 29, 2004, at 1:11 PM, Lowrie, Tom wrote:
Adding -lcfg along with -lodm solves my problem. Thanks for the
push in the right direction.
Next step will be to figure how to compile the libpcap source so
that these libraries are included.
The standard libpcap build procedure in the main CVS
On Jul 30, 2004, at 10:14 AM, Greg Weiss wrote:
Is there a way to command-line filter tcpdump so that only packets with
bad TCP checksums are dumped?
No.
The BPF filtering mechanism can't handle it, as there's no way for it
to compute a checksum, and the filtering mechanism is BPF-based.
A
On Mon, Aug 09, 2004 at 01:08:49AM +1000, Darren Reed wrote:
In some email I received from Fulvio Risso, sie wrote:
Darren, could you please give us some numbers?
If you take a look at this paper:
F. Risso, L. Degioanni
An architecture for high performance network analysis
On Aug 25, 2004, at 11:05 AM, David Front wrote:
11:33:55.601653 IP lxfs5623.cern.ch.32962 lcgmon002d.cern.ch.12509:
UDP, length: 1637
UDP, length: 1637 means that the *UDP* packet length is 1637 bytes.
That doesn't mean that the *Ethernet* packet is 1637 bytes, as you note
later:
IP message
On Aug 25, 2004, at 11:09 AM, Guy Harris wrote:
Note, however, that the reassembly is *NOT* done at the low-layer
capture level, so a capture filter of port 12509 will only capture
the first fragment of a fragmented datagram, and Ethereal and
Tethereal will *NOT* be able to reassemble
On Aug 26, 2004, at 3:43 PM, Chris Reining wrote:
I am running into an interesting promiscuous mode issue on Redhat
Enterprise WS 3, kernel version 2.4.21, libpcap version 0.7.2 and
tcpdump 3.7.2. The issue is unanticipated toggling of promisc state. I
am running Snort version 2.1.2 which itself
On Sep 3, 2004, at 3:48 AM, Sebastien Vincent wrote:
So I made changes into ./tcpdump.c and it now works fine.
Checked in.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Sep 13, 2004, at 4:24 PM, Rick Jones wrote:
For other nefarious porpoises I downloaded libpcap and tcpudmp
currents on 2004-09-13 and did straight-up ./configure;make on HP-UX
11.11 (aka 11i v1) using the HP compiler. This system did not have
the TOUR installed to get IPv6 functionality.
Shaun wrote:
Or get a DAG card? Not sure if they support FreeBSD though.
http://www.endace.com/faq.htm#linux
Q: Do you support any other operating systems than Linux? Do you
support BSD or Solaris?
A: Linux is the primary platform for the DAG product range, with robust
support. A device
On Sep 14, 2004, at 10:33 AM, Rick Jones wrote:
well, with the link in place, i did the make dist clean then the
configure then the make and did get the duplicate symbols. so, here
is the config.log
...
configure:8312: checking for local pcap library
configure:8420: result:
On Sep 14, 2004, at 4:38 PM, Rick Jones wrote:
no datalinks.o:
LOCALSRC = print-smb.c smbutil.c
GENSRC = version.c
LIBOBJS = strlcat$U.o strlcpy$U.o strsep$U.o
But you got duplicate symbol errors?
What's the output of make?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to
On Sep 15, 2004, at 12:37 AM, Matthew Luckie wrote:
There is code in pcap-bpf.c to set the selectable fd to -1 if it is
detected the OS is FreeBSD 4.3 or 4.4
I don't think the check actually successfully detects 4.3 or 4.4, as
the osinfo.release parameter will have something like 4.3-RELEASE or
On Sep 17, 2004, at 3:20 PM, Paul Berube wrote:
One question, though. I see h.m.s:ms, a.b.c.d.x:, and I'm wondering
what the 'x' is? By the frequent occurences of 80, I'm guessing these
are
port numbers, but I'd like to be sure :)
Yes.
this won't work with icmp though...
That's fine, I'm only
(Blah blah blah work around duplicate message detector blah blah blah
someday I'll figure out if I can configure Thunderbird to know that all
tcpdump-workers mail should come from my alum.mit.edu address blah blah
blah.)
David Young wrote:
Here is support for radiotap, an extensible radio
(blah blah blah duplicate posts blah blah blah thunderbird blah blah
blah multiple accounts blah blah blah)
Guy Harris wrote:
Looks good to me, at least for the top-of-tree (where we require that
the platform support 64-bit integers, and where we define u_int64_t to
be an unsigned 64-bit integer
Claudio Lavecchia wrote:
3. How do you calculate size_ip?
int size_ip = sizeof(struct sniff_ip);
Do any of the packets have IP options? If so, then that's *not* the
size of the IP header.
You should get the IP header length from the header length/version field
from the IP header (and should
Matthew Luckie wrote:
The motivation for this patch was to obtain something resembling the
timestamp closest to when a packet I generated and transmitted hit the
wire, to infer a more accurate RTT with an associated response packet.
That's certainly a worthy goal, but the patch might not help
On Sep 24, 2004, at 6:02 AM, Hannes Gredler wrote:
any suggestion for a x.9 branch date ? what about 31-oct-04 ?
Speaking of x.9 branch, should the VERSION files in libpcap and
tcpdump change to 0.9-PRE-CVS and 3.9-PRE-CVS, respectively?
-
This is the tcpdump-workers list.
Visit
(blah blah blah wrong from address blah blah blah duplicate message
dissector blah blah blah time to see whether I can configure Thunderbird
to automatically set the from address for tcpdump-workers messages blah
blah blah)
KEVIN ZEMBOWER wrote:
www:~# tcpdump src host centernet.jhuccp.org and
KEVIN ZEMBOWER wrote:
As you can see, I'm still getting packets from ns1.jhmi.edu on the DNS port.
What does the command
tcpdump -d src host centernet.jhuccp.org and \( ip proto \\tcp or \\udp \)
print?
If it helps, I'm using bash 2.05 on a Debian woody (stable, 3.0) distro
running kernal
Sorry I didn't get around to this until now, but
On Jul 30, 2004, at 1:09 PM, Gianluca Varenni wrote:
There is another issue related to these block types.
Fulvio's proposal:
a shb (even corrupted by the ftp transfer) can begin with the following
strings:
\r\n\r\x1A - 1 reserved block type
On Oct 18, 2004, at 3:04 PM, Alexander Dupuy wrote:
Guy Harris writes:
Unfortunately, given that, on systems with BPF, you cannot change the
buffer size after a BPF device has been bound to a network interface,
pcap_setbuff() is unimplementable on those systems, so it's not a
candidate
akshar SNIFFER wrote:
I am writing a sniffer in C++ ,
Then this is a question that belongs in the tcpdump-workers list, not
the ethereal-dev list, so I'm redirecting it there.
I have included the pcap.h header file .While compiling i get the following error
Gerard Beekmans wrote:
tcpdump.o(.text+0x947): In function `main':
: undefined reference to `pcap_debug'
collect2: ld returned 1 exit status
What does
nm -o ../libpcap-0.8.3/libpcap.a | egrep pcap_dump
print, and...
Configure did check for, and found, pcap_debug:
checking whether
On Oct 25, 2004, at 1:27 PM, Ying Li wrote:
Sometimes select() times out way too
fast, like 0.0001 seconds while my timevar is set to
0.001 sec.
Times out in the sense that retval is 0?
On what OS are you doing this?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to
Pete Wilson wrote:
I'm a new user of tcpdump, so please forgive these few amateur
questions.
1. I need to look at SNMP traffic, so I issue:
node2:/root#tcpdump udp host node1 or node2 or node3
tcpdump: 'udp' modifier applied to host
UDP doesn't know about hosts - that's IP's responsibility.
Matt Van Mater wrote:
Recently I've been investigating why tcpdump on my IDS shows quite a few
packets as being dropped.
Probably because it's receiving so many packets that it can't keep up.
Drops, as reported by tcpdump, are drops due to the buffer in the packet
capture mechanism overflowing
On Oct 31, 2004, at 6:15 PM, Pete Wilson wrote:
although do you want to exclude TCP or exclude everything but UDP
(or exclude everything but port-161 and port-162 UDP traffic)?
Well, since you ask :-) Yes, sure.
Then that's where the
If you want to see all UDP traffic to and from particular hosts
(Blah blah blah oops I did it again blah blah blah avoid duplicate
message detection blah blah blah.)
Kathy Chen wrote:
I want to know in what situations the machine's
network is set to promiscuous mode.
It's put into promiscuous mode if an application requests that the
interface be put into
On Nov 16, 2004, at 1:08 PM, jesk wrote:
in some auth-replies iam missing some attributes but instead of them i
can see at the end of a tcpdump line the following:
[|radius]
what does this exactly mean?
It probably means that either
1) the RADIUS packet didn't fit in a single link-layer packet
1 - 100 of 1943 matches
Mail list logo