Christian Stålp wrote:
Argh, thats are very very sad news. That dumps all my ideas. My project
was to track the retry field and in case of a dramitical increase switch
over to the monitor mode, and see what wrong. Maybe you see some
pattern, some events? My idea was to obserse which station in
Christian Stalp wrote:
And one question more, how can I use monitore-mode for normal traffic?
I.e., you want to run in monitor mode while still using the adapter for
normal traffic?
Whether you can do that depends on the adapter and the driver; as I
understand it, some adapters can support
Gaurav Garg wrote:
I am currently working on porting some of the packet driver code from
Windows to Linux. I am left with the *pcap_sendpacket()* function. I
searched through the archive on the website, but could not find the
implementation of this function in pcap-linux.c file.
If you have
Hannes Kälber wrote:
Since we are capturing automotive busses, such as CAN, Flexray, Most and
LIN, I suggest that these busses get there own DLTs.
I suggest the names
DLT_FLEXRAY
DLT_MOST
DLT_LIN
I've assigned those:
DLT_FLEXRAY 210
DLT_MOST211
vcarela wrote:
The problem is that if I capture with wireshark a trace from my eth0
connection and I save it as a "Wireshark/tcpdump/...-libpcap" file. Then
when I run the sniffer with this pcap trace the sniffer runs properly.
But if I open a .erf trace from a DAG card with wireshark and I sav
On Mar 11, 2008, at 1:15 PM, Stephen Donnelly wrote:
When you save a capture in libpcap format Wireshark doesn't prompt you
for which DLT to use?
No. That's supposed to happen automatically.
How does it decide which DLT is appropriate?
It decides based on the encapsulation type of the in
sagun shakya wrote:
Being new to the process of submitting patches here, do I need to
provide a patch via the patch tracker in sourceforge.net or uploading
the diff and new files to the bugid will suffice? Please let me know.
So what license/copyright should be applied to pcap-libdlpi.c? A l
On Mar 1, 2008, at 6:10 AM, Kris Katterjohn wrote:
Bruce M Simpson wrote:
|
| You might want to look in XORP for a fairly rigorous set of
| platform-independent autoconf tests, including (if memory serves me
| right) socklen_t.
Thanks, but my check should be platform-independent as well.
...
Bruce M Simpson wrote:
+1 here.
Zero copy BPF has just gone into FreeBSD-CURRENT. It would be great to
have a snap which can do this too. Christian Peron (CC'd) has been
responsible for the code.
That means that we *don't* want to take what we have now and release it,
as we don't currently
sagun shakya wrote:
I have been trying to access the tcpdump.org site but it seems to be
down. So I'll ask my question here. Does the development gate (cvs
repository) correspond to the releases of the current version?
The CVS repository has all the releases that tcpdump.org has put out;
the
On Apr 1, 2008, at 2:03 AM, Milosz Marian Hulboj wrote:
I would like to know whether it is possible with the current pcap
format to
store the captured packets in the fixed length blocks in the file.
What "fixed length blocks" are you referring to? The current file
format has
1)
Milosz Marian Hulboj wrote:
What I meant was to store the captured packets in the blocks of fixed size
(possibly wasting some of the storage space in case of small packets, but
gaining in case one wishes to do random access). So to access packet $n$ I
would have to look at the offset = header
Christian S.J. Peron wrote:
I have attached the patch that we have been using. This is a patch for the
libpcap code in FreeBSD -CURRENT right now. It appears to work well, but
you folks might have some ideas for getting the necessary autoconf magic
in, as well make some possible architecture cha
sagun shakya wrote:
When the features mentioned above integrate into Solaris, an extensible
way to open DLPI links under different directories will be required. The
libdlpi(3LIB) library provides an interface that provides an abstraction
around this so that DLPI applications do not need to kno
Stephen Donnelly wrote:
pcap-dag.c 1.37 doesn't compile after changes to support the new
'activate' model.
Small patch which should address the issues.
Checked into the main and 1.0 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Gianluca Varenni wrote:
Within WinPcap I have a big problem in generating the documentation.
Within WinPcap we generate html with doxygen out of an (outdated)
version of pcap.h. In the past it was a pain because the pcap.h file
used for the documentation was never up-to-date.
The problem is t
David Rosal wrote:
As far as I know, each network interface (for example eth0), can have
different adresses, because in pcap_findalldevs(), a pcap_if_t does not hold
a single pcap_addr_t but a linked list of all addresses for each
interface/device.
Yes, it can have multiple addresses, and, ye
David Rosal wrote:
Well, libpcap++ is only a wrapper, and it does not add any new feature to
libpcap, except maybe the abbility to retrieve some attributes of pcap
descriptors that are hidden in libpcap.
What do you mean by "some attributes of pcap descriptors that are hidden
in libpcap"? Be
Matthew Topper wrote:
I posted patches to the sourceforge projects of both tcpdump and libpcap
which together enabled capturing packets for a given number of seconds. I
don't really see any activity on either sites, so I was hoping that
someone here could tell me how I should proceed, and if I'v
Michael Richardson wrote:
Only... -P is used somewhere else, in another patch, I think.
We gotta get 4.0 out, with long options...
tcpdump currently still uses getopt(), so it doesn't support long options.
Should we switch to getopt_long(), and include a BSD-licensed
getopt_long() (e.g., one
Alan McKay wrote:
Except that the version with FC8 does not have -z option, and when I
download and build the latest from your website (3.9.8) it does not
seem to either.
Though if I look at the manpage on your website, it is from 15 June
2007 and lists a -z option.
So how do I get this option?
Gisle Vanem wrote:
The recent change for pcap_activate() broke the DOS-port.
Here's a small fix:
Checked into the main and 1.0 branches, along with some changes and
other fixes.
p->activate_op = pcap_activate_dos;
+ p->md.device = device;
I just changed it to use opt.device r
Gisle Vanem wrote:
Ok, but I reckoned PCAP_ERROR was too vague. I'm not sure what
errorcode would cover this case.
Perhaps we should add a new error code.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Gisle Vanem wrote:
Two more details:
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Gisle Vanem wrote:
* gnuc.c not needed.
* sys/pack*.h was renamed in a recent Watt-32 distro.
Checked into the main and 1.0 branches (as were the changes I previously
checked in).
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
Gisle Vanem wrote:
Ok, but I reckoned PCAP_ERROR was too vague. I'm not sure what
errorcode would cover this case.
Perhaps we should add a new error code.
So what *is* this case? The error message is "Cannot use different
devices simultaneously"; does tha
Adamiec, Larry wrote:
I am trying to install libpcap-0.9.8 on a Sun SPARC Solaris 9 server. I
need to install it with shared libraries.
That's not currently supported by our build procedure. The person who
contributed that support just contributed Linux support (which might
work on other p
On May 13, 2008, at 4:23 PM, Phil Wood wrote:
On linux, the shared libraries end up in a hidden directory
named .libs
...if the shared library you're building uses libtool. As noted in
that thread, libpcap currently doesn't use libtool.
-
This is the tcpdump-workers list.
Visit https://c
Chris Pawelko wrote:
I am using tcpdump with the -w and -v options.
Presumably meaning that you're sometimes using tcpdump with -w and other
times using tcpdump with -v - if "-w" is being used, it's writing a raw
binary capture to the file, not writing a dissected text display of the
packets
On May 23, 2008, at 12:44 PM, Chris Pawelko wrote:
Has anybody heard of or had run tcpdump as a daemon?
If so are there any instructions?
"Run[ning] tcpdump as a daemon" is too general of an operation to have
a single simple set of instructions; do you want to have:
a daemon that starts
Bruce M Simpson wrote:
You probably want bpft, not tcpdump.
Presumably that's the BPF Traffic collector:
http://bpft4.sourceforge.net/
as opposed to the Batu Pahat Ferry Terminal or the Brockport Physical
Fitness Test
-
This is the tcpdump-workers list.
Visit https://cod.sandel
Michael Fisher wrote:
I am having a issue with pcap_next() and any other pcap call. I have
several modules in my program but in one one module i make the
pcap_open_live call
It isn't returning a null pointer, right?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubsc
(This is a libpcap issue, not a Wireshark issue, so I removed the
Wireshark mailing list.
In addition, the correct address for the tcpdump-workers list is tcpdump-workers@lists.tcpdump.org
, not [EMAIL PROTECTED]; the latter bounces. CCing
Nirupama, in case they're not on the tcpdump-worker
khaled wrote:
thank you
but exist an other methode?
You could use pcap_next_ex(), for example.
who uses C
The tcpdump and Wireshark developers do, to give two examples.
The third argument to pcap_loop() isn't only useful for C++; it was, in
fact, originally designed for use in C.
-
This
sufei7099 wrote:
How to install libpcap on SCO OPEN SERVER? I download the latest
version of libpcap, but I can not install it on sco successfully. The
phenomena is that some macro definition can not be found. I am wishing
for your help.
To quote the INSTALL.txt file in the latest version of l
[EMAIL PROTECTED] wrote:
I'm new to the tcpdump code and I'm looking for some direction as to
where the screen output takes place. I'm trying to capture that output
and send it via OpenSoundControl messages to the SuperCollider music
technology programming system.
"Capture" in what sense?
On
[EMAIL PROTECTED] wrote:
I tried piping to the SuperCollider program, but I'm guessing I would
have to edit the SuperCollider code then so that I can tell it what to
do with the Piped data?
Try, instead, writing a program that
1) reads tcpdump output
and
2) based on what it reads,
On Jun 10, 2008, at 12:18 AM, linzw wrote:
I want to compile the Snort in SCO Openserver, and the first I
should compile libpcap, But I don't kown wether libpcap support for
SCO Openserver.
To quote the libpcap INSTALL.txt file:
If you use SCO, you might have trouble building libpcap
On Jun 11, 2008, at 6:44 PM, sufei7099 wrote:
the following is the faults when I run make after run ./configure:
What was the output of ./configure?
"pcap-dlpi.c", line 699: error: undefined symbol: DL_PROMISC_PHYS
Googling for DL_PROMISC_PHYS on any sco.com site found no hits.
This coul
On Jun 11, 2008, at 7:14 PM, sufei7099 wrote:
The output of "ls -l /usr/include/sys/dlpi.h" is:
lrwxrwxrwx 1 root root 38 Jun 4 11:46 /usr/include/
sys/dlpi.h -> /opt/K/SCO/lli/5.0.7a/llicompat/dlpi.h
What does
ls -l /opt/K/SCO/lli/5.0.7a/llicompat/dlpi.h
print?
On Jun 11, 2008, at 7:32 PM, Michael Bernstein wrote:
I think mainly all IPS/IDS are based on TCPdump filters and
translation into IDS rules.
I don't think that's the case, at least if it's "all IPS/IDS" rather
than "most IPS/IDS". A quick look at the "community" rules for Snort
CURRENT
On Jun 11, 2008, at 7:49 PM, sufei7099 wrote:
the result is:
-rw-r--r-- 1 bin bin21089 Jun 4 11:40 /opt/K/SCO/
lli/5.0.7a/llicompat/dlpi.h
What does
egrep DL_PROMISC_PHYS /opt/K/SCO/lli/5.0.7a/llicompat/dlpi.h
print?
Is there some methods to resolve it ? or it mea
sufei7099 wrote:
It's print nothing.
I suspected it would.
Are you running OpenServer 5, OpenServer 6, That means that the code
in libpcap's pcap-dlpi.c probably can't easily be made to work on
OpenServer 5. About the only thing I can suggest is to try replacing the
#include
f
On Jun 12, 2008, at 2:56 PM, Eloy Paris wrote:
However, other applications may want to do more than capturing,
dissecting, and presenting results, like capturing packets and then
taking some action, like sending a response back, or performing some
type of analysis that tcpdump and wireshark can
sufei7099 wrote:
/bin/ksh ./libtool --mode=compile cc -DHAVE_CONFIG_H -D_U_="" -I.
-I/usr/local/include-g -belf -c fad-gifc.c
cc -DHAVE_CONFIG_H -D_U_= -I. -I/usr/local/include -g -belf -c fad-gifc.c -o
fad-gifc.o
"/usr/include/sys/file.h", line 61: error: Syntax error before or
sufei7099 wrote:
I think I have install the libpcap on SCO successfully.
Did you do so by changing the Makefile not to try to build fad-gifc.c?
If so, then:
undefined first referenced
symbol in file
pcap_findalldevsmypcap
sufei7099 wrote:
I add the #incude in file.h,
I.e., you changed /usr/include/sys/file.h to include ?
Does /usr/include/sys/param.h include on your system?
then i make successfully. After i run make install, the result is :
# make install
...
rm -f /usr/local/inc
Bruce Keats wrote:
I have a program that is listening on a radio tap interface that is using
libpcap. It occasionally changes the BPF something like "ether host
xx:xx:xx:xx:xx:xx".
...which presumably means it calls pcap_compile() more than once.
Is there a fix for this issue?
Yes:
revis
sherin hagag wrote:
i m student in IGSR in egypt ,i prepare master in streaming
multimedia,i want to ask if tcpdump could be installed on windows
The version of tcpdump compiled for Windows is called WinDump:
http://www.winpcap.org/windump/install/default.htm
Before you install WinDu
Tassadaque Zia wrote:
I am using libpcap. I want to perform a task as packet arrive on
network interface. which method of libpap should i use to capture the
"packet arrival event"
Libpcap doesn't deliver events, it delivers packets.
Therefore, you should just read packets with, for example,
Ignacio, Domingo Jr Ostria - igndo001 wrote:
I inserted a new variable, srtt, into the print_tcp.h header file and
tcp.c source code.
(Presumably you meant "tcp.h header file and print-tcp.c source code".)
If you inserted it into the "struct tcphdr" structure, that's a mistake.
That stru
On Jul 1, 2008, at 4:32 PM, grarpamp wrote:
Hi. Surely it is not possible to have both 'no flags' and
present at the same time? The man page has a few
references to the dot, particularly in the 'OUTPUT FORMAT - TCP
Packets' example near 'means no flags'.
The man page apparently needs to be u
grarpamp wrote:
Hi. I think I've found this 'none' printf you speak of.
More precisely it's a "none" argument passed to bittok2str_nosep() plus the
else {
/* bummer - lets print the "unknown" message as advised in
the fmt string if we got one */
if (fmt == NUL
grarpamp wrote:
Hi. Patch inline. I conformed the naming to the RFC's
I assume by "naming" you are referring not only to the bits used to
print the flags in tcpdump but also the flag values used in libpcap for
filters.
Perhaps a name using the "psh" abbreviation used by RFC 793 for the
"pu
On Jul 7, 2008, at 11:04 AM, Jacek Jablonski wrote:
I applied such filter to my sniffer:
"tcp and port 8071"
The problem is that, outgoing packets are fine, they are captured one
time, but incoming packets are captured twice and they are interpreted
two times.
Does that happen if you *don't*
On Jul 8, 2008, at 3:33 AM, Milosz Marian Hulboj wrote:
I know that it is not possible to use pcap_stats when reading data
from a savefile.
That's because the statistics aren't recorded in the savefile.
I can count the packets returned by the pcap_next_ex, but if I
applied a filter, this
On Jul 13, 2008, at 10:01 PM, Ignacio, Domingo Jr Ostria - igndo001
wrote:
Is there a filter command where we can only specify to capture
specifically the sequence number of a tcp packet header?
If you want to capture packets with a particular value of the sequence
number, try
On Jul 15, 2008, at 12:57 AM, Ignacio, Domingo Jr Ostria - igndo001
wrote:
I try to modify print-tcp.c and tcp.h source code and header file file
of tcpdump-3.9.8 to include a new option which is th_srtt, a
variable I
added to my linux kernel protocol stacks.
Where did you add that opti
On Jul 16, 2008, at 12:09 AM, Ignacio, Domingo Jr Ostria - igndo001
wrote:
Or 2. When the tcpdump do the packet capture, is it looking/utilizing
the kernel variables within the protocol stacks or it is operating
independently from the kernel?
It is *not* utilizing kernel variables in the T
On Jul 16, 2008, at 1:08 AM, Ignacio, Domingo Jr Ostria - igndo001
wrote:
I inspected and studied the linux kernel source codes, tcp_input.c,
tcp_ouput.c, tcp_ipv4.c and tcp.c and it is only on the tcp_input
source
code where there is a provision on TCP options to be added.
No, the TCP
On Jul 16, 2008, at 5:10 AM, Patrick McHardy wrote:
This patch adds support to libpcap to retrieve the tag from
the auxillary data and reconstruct the original VLAN header,
solving a major complaint about the way Linux handles VLAN
offloading.
Unfortunately both the website and CVS is down, so
On Jul 18, 2008, at 6:59 AM, rabiy ezou wrote:
I have project and I need lipcap but I can't download the package
from www.tcpdump.org.
I have always an error message when I try to download
There appears to be a networking problem of some sort that's
preventing access to www.tcpdump.org (a
On Jul 30, 2008, at 2:12 PM, Stephen Donnelly wrote:
I recently came across some packets which tcpdump appears to display
incorrectly.
Is tcpdump incorrectly invoking some heuristic dissector, or is there
another reason?
I guess that's what I'd call it.
tcpdump assumes that packets to or fr
On Jul 31, 2008, at 5:52 AM, U. George wrote:
BUT if i remove the 'port domain' i see all the packets:
[EMAIL PROTECTED] gat]# /usr/sbin/tcpdump -v -n -i eth1 tcpdump:
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
08:49:38.834343 PPPoE [ses 0xea20] [length 48 (4 ext
On Jul 31, 2008, at 10:48 AM, U. George wrote:
why does adding the "PORT" conditional also modify the wild-card
aspects of "ethernet type"
To what "wild-card aspects of 'ethernet type'" are you referring?
If you say "port domain", that can only match TCP or UDP packets,
which means it can
On Jul 31, 2008, at 11:11 AM, U. George wrote:
[EMAIL PROTECTED] MyRblsmtpd]# /usr/sbin/tcpdump -n -v -i eth1
pppoes and port domain
tcpdump: syntax error
PPPoE is not in my tcpdump man page :{
To quote my original mail:
If the DNS requests are on PPPoE, then, *at least with a
suffici
On Jul 31, 2008, at 11:29 AM, U. George wrote:
if i say this:
tcpdump -n -v -i eth1
i get a log of: ether type * and port *, ie the PPPoE data.
What you get is a log of "*", i.e. all data. "port *" is irrelevant;
not all packets that would match "ether type *" *HAVE* a port numbe
On Jul 31, 2008, at 8:53 PM, U. George wrote:
Guy Harris wrote:
On Jul 31, 2008, at 11:29 AM, U. George wrote:
if i say this:
tcpdump -n -v -i eth1
i get a log of: ether type * and port *, ie the PPPoE data.
What you get is a log of "*", i.e. all data. "port *" i
On Aug 1, 2008, at 12:36 AM, Gert Doering wrote:
On Thu, Jul 31, 2008 at 11:53:27PM -0400, U. George wrote:
Without a detailed study, on my part, I am unable to jump to that
conclusion.
There is nothing to "study" here, or any conclusion to "jump to".
Guy has described the way tcpdump curre
On Jul 18, 2008, at 10:53 AM, Patrick McHardy wrote:
Please keep me CCed since I'm not subscribed to the list.
commit 6f5556e515578c3e034b176562633987e85782e5
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Fri Jul 18 19:22:52 2008 +0200
pcap-linux: fix invalid rcvbuf size
Libpcap
On Jul 18, 2008, at 11:07 AM, Patrick McHardy wrote:
pcap-linux: reconstruct VLAN header from PACKET_AUXDATA
From: Patrick McHardy <[EMAIL PROTECTED]>
VLAN packets sent over devices supporting VLAN tagging/stripping in
hardwaredon't have a VLAN header when they are received on packet
sockets.
On Jul 18, 2008, at 11:07 AM, Patrick McHardy wrote:
pcap-linux: convert to recvmsg()
From: Patrick McHardy <[EMAIL PROTECTED]>
Convert pcap-linux to use recvmsg() as preparation for using
PACKET_AUXDATA
cmsgs.
Checked into the main and 1.0 branches.
-
This is the tcpdump-workers list.
V
On Jul 18, 2008, at 11:08 AM, Patrick McHardy wrote:
pcap-linux: support new tpacket frame header format
From: Patrick McHardy <[EMAIL PROTECTED]>
The tpacket_hdr is not clean for 64 bit kernel/32 bit userspace and
is not extendable because the struct sockaddr_ll following it is
expected at a
On Jul 18, 2008, at 11:08 AM, Patrick McHardy wrote:
pcap-linux: reconstruct VLAN headers from tpacket2_hdr
From: Patrick McHardy <[EMAIL PROTECTED]>
Similar to PACKET_AUXDATA for non-mmaped sockets, the VLAN TCI is
present in a new member of struct tpacket2_hdr. Use it to reconstruct
the VLA
On Jul 18, 2008, at 11:06 AM, Patrick McHardy wrote:
The patches are compile-time and run-time compatible with
old headers and kernels.
After applying the patches, libpcap didn't compile on my vanilla
Ubuntu 7.10 virtual machine, as the tpacket_auxdata structure didn't
have a tp_vlan_tci
On Aug 12, 2008, at 12:05 AM, Francois-Xavier Le Bail wrote:
Try :
tcpdump -r xx > log_ftp
less log_ftp
Or just
tcpdump -r xx | less
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Sep 8, 2008, at 6:27 AM, lei wei wrote:
By "unacceptable", I mean the number of packets that tcpdump
processed was
only a fraction
of that of it received. I assume that "Number of Packets received by
filter"
are the packets were
matched by the filter expression,
No.
On systems with B
On Sep 9, 2008, at 9:17 AM, lei wei wrote:
Thanks a lot for the reply Guy! According to your explanation, for
libpcap, the status struct:
struct pcap_stat {
u_int ps_recv;/* number of packets received */
u_int ps_drop;/* number of packets dropped */
the ps_recv field
On Sep 9, 2008, at 7:02 PM, lei wei wrote:
I'm trying to capture packets from two network interfaces on FreeBSD
using
pcap. From what I read about,
a "-i any" can be used on Linux to capture from all interfaces. But
FreeBSD
doesnt seem to recognize it.
BPF devices, unlike Linux PF_PACKET
On Sep 9, 2008, at 10:21 PM, Munish Dayal wrote:
I have built Wireshark from source on my Linux RHEL 4 system, that
has libpcap version 0.8.3 installed.
But when I try to run this Wireshark on a Linux system with RHEL 5
(libpcap version 0.9.4), I get an error:
"error while loading shared l
On Sep 10, 2008, at 4:20 AM, Munish Dayal wrote:
ls -l /usr/lib/libpcap.*
-rw-r--r-- 1 root root 242398 Jul 13 2006 /usr/lib/libpcap.a
lrwxrwxrwx 1 root root 16 Sep 10 16:24 /usr/lib/libpcap.so ->
libpcap.so.0.9.4
lrwxrwxrwx 1 root root 16 Jul 9 17:21 /usr/lib/libpcap.so.0 ->
l
On Sep 15, 2008, at 2:05 PM, Dmitry wrote:
Test one:
I've opened dump with wireshark.
Found stream, filtered it out and saved raw data to file 'dump.hex'
What do you mean by "raw data"? Do you mean raw *binary* data, or raw
data as a hex dump?
And did you save the raw contents of the pac
On Sep 12, 2008, at 6:30 AM, Christian Peron wrote:
I have included a patch for review. This adds zero-copy bpf support
to libpcap. It should be noted that I've tried to incorporate all
the feedback that I recieved after the previous submission.
Looks good.
I've checked it into the main an
On Sep 16, 2008, at 1:00 AM, Guy Harris wrote:
Also, note that there's an API to set the buffer size; perhaps, if
that API was called - i.e., if p->opt.buffer_size is non-zero - it
should set the mapped buffer size based on that.
I've checked in code that should handle t
On Sep 17, 2008, at 2:26 PM, Robert Edmonds wrote:
the comparison succeeds because the large unsigned k-value for this
instruction (0xfff0) is much larger than the number of remaining
bpf
instructions (flen-pc-1).
It's so large, in fact, that its high-order bit is set - so, in
effect
On Sep 18, 2008, at 8:23 PM, Robert Edmonds wrote:
right, but the LSF filter validation code treats it as unsigned.
Doesn't matter - whether the problem is that the branch goes too far
forward, or goes backward, it's not something the kernel can accept
(and we're talking about a 1-sphere
On Sep 18, 2008, at 3:23 PM, arun chhetri wrote:
Can, you guys please tell me how to parse a tcpdump dump file with C+
+.
Use libpcap to read packets from the dump file.
That will give you the raw contents of the packets. Parsing the raw
packet data is left as an exercise to the reader.
On Sep 19, 2008, at 8:16 PM, Ben Greear wrote:
I noticed that pcap_setdirection doesn't appear to work on Solaris.
Anyone know if it would be possible to get this functionality
implemented?
Libpcap runs atop DLPI in Solaris. In my experience with at least one
version of Solaris, if you
On Sep 20, 2008, at 8:42 AM, Ben Greear wrote:
To be a bridge, you have to receive all traffic, so disabling
PROMISC isn't really an option as far as I can tell.
Oh, well. A quick look at the GLD driver in OpenSolaris (/usr/src/uts/
common/io/gld.c; see cvs.opensolaris.org) seems to indica
On Sep 21, 2008, at 9:18 AM, осьмилис wrote:
I would like to request a new DLT value for 802.15.4 Low rate wireless
personal area networks that will represent packets at PHY level, as
specified
in http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf and
http://standards.ieee.org/g
On Sep 22, 2008, at 2:54 AM, Макс Филиппов wrote:
No ASK PHY, only those described in 2003's standard.
So the packet's data will begin with 4 octets of 0 (the preamble),
followed by one octet of SFD, followed by one octet of frame length +
one reserved bit, followed by the MAC-layer data,
On Sep 22, 2008, at 10:47 AM, Max Filippov wrote:
So the packet's data will begin with 4 octets of 0 (the preamble),
followed by one octet of SFD, followed by one octet of frame length +
one reserved bit, followed by the MAC-layer data, starting with the
2-
octet frame control field?-
Yes,
On Sep 22, 2008, at 8:30 AM, Gisle Vanem wrote:
bzero() and bcopy() are not universally available. But
memset() and memcpy() are AFAICS.
Yes - they're in the ANSI C standard, so if you don't have them you're
using a really old crufty platform.
Attached diffs-5.txt.
Checked into the mai
On Sep 23, 2008, at 9:01 AM, lei wei wrote:
I mean if there's no traffic currently from the interface, will
tcpdump keep
reading from it until traffic comes?
Yes (or until you interrupt it with ^C or whatever your interrupt
character is).
-
This is the tcpdump-workers list.
Visit https:/
On Sep 25, 2008, at 12:31 AM, Munish Dayal wrote:
I am still facing this problem. Any suggestions?
Do I have to downgrade the libpcap from version 0.9.4 to 0.8.3 on
RHEL-5 system, in order to be able to run Wireshark on it.
(Wireshark rpm built on RHEL-4 system).
Or build Wireshark on the
On Oct 3, 2008, at 12:43 PM, Rodrigo Roldan wrote:
I am trying put a "label" into tcpdump code for identify different
interfaces when i run "tcpdump -i any"..
Libpcap does not, when capturing on the "any" device, supply any
indication of the interface on which a packet arrived.
(Note also
On Oct 7, 2008, at 1:07 PM, Jim Mellander wrote:
All of the above are attempts to overcome the 'one filter per
interface
per process' model that I believe libpcap imposes - or am I wrong? Is
there something I've overlooked?
Depends on what you mean by "imposes".
If you want to do filterin
On Oct 7, 2008, at 1:07 PM, Jim Mellander wrote:
All of the above are attempts to overcome the 'one filter per
interface
per process' model that I believe libpcap imposes
So why does it need overcoming? A filter says "only deliver me
packets that match the following"; would multiple pack
On Oct 14, 2008, at 9:30 AM, Max Laier wrote:
Depends on the platform you are on. On FreeBSD all you need is read
write
permission to the /dev/bpf* devices.
Also true in NetBSD, OpenBSD, DragonFly BSD, Mac OS X, and, I think,
AIX. (And, at least with some versions of libpcap, all you ne
On Oct 15, 2008, at 6:50 PM, Ken Bantoft wrote:
I uploaded Release Candidate 2 to http://www.tcpdump.org/beta this
evening - please give it a test and make sure it works as you
expect. I'm want to ship it by the end of the month (this time, I
promise!), as it's been stable for quite some
901 - 1000 of 2521 matches
Mail list logo
