On Jan 6, 2008, at 12:54 PM, Guy Harris wrote:
Would it work better if, for PF_RING sockets, there were a separate
pcap_read_pf_ring, and handle->read_op were set to pcap_read_pf_ring
if a PF_RING socket were being used? That'd avoid some per-packet
checks in the read_op rout
Michael Richardson wrote:
What problem is the ultra-open parameter list supposed to solve?
1) allow open options to be added without having to change the signature
of the open-live routine, so that we don't have to anticipate all the
options that might ever want to be added.
2) allow a app
On Jan 13, 2008, at 3:33 PM, Michael Richardson wrote:
I.e. we should instead have a new pcap_open() call, and then we
should
have a serious of calls that set various options or ask for various
things based upon that handle.
Thus:
pcap_t pcap_open_live(char *device, int snaplen, int promis
Luca Deri wrote:
I have considered your suggestion to move pfring into a pcap-pfring.*
file.
I didn't make such a suggestion.
I did say
Would it work better if, for PF_RING sockets, there were a separate
pcap_read_pf_ring, and handle->read_op were set to pcap_read_pf_ring if
a PF_RING socke
Ian Brown wrote:
- I tried sniffing in various ways , like by "tcpdump -f vlan" and
"tcpdump -f vlan and net 192.168.0.0" and "tcpdump -f vlan and udp
port 9" and many other ways . on both sides,
(192.168.0.10 and the source machine , where pktgen runs) but I could
not catch any VLAN frames.
Ian Brown wrote:
It is 8139 (RTL).
Yes, but what interface name were you capturing on? eth0 (which I'm
assuming is the RTL 8139 adapter in question), or some other interface
(or pseudo-interface)?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Alfred E. Heggestad wrote:
I am wondering if there is a libpcap option to do automatic
reassembly of UDP/IP packets inside the library?
No. Libpcap is, by design and intent, a low-level library for capturing
and sending raw link-layer packets.
If not then
I guess the solution is to implem
Peter Memishian wrote:
> I mostly fixed the comment changes, thinking they were trivial and left
> other Sun cstyle error alone. I can see how it is distracting while
> reviewing the actual changes.
It's more than distracting -- it's incorrect. Code for libpcap follows
its own style
It
sagun shakya wrote:
I mostly fixed the comment changes, thinking they were trivial and left
other Sun cstyle error alone. I can see how it is distracting while
reviewing the actual changes. I've undone such changes and posted a new
webrev at:
http://cr.opensolaris.org/~sagun/libpcap/
pcap
On Feb 1, 2008, at 10:10 AM, Sebastien Roy wrote:
* 118-123: I would think that in 2008, most compilers can do a
better job at assigning register use than this (making every single
variable a "register" variable.) You don't have to fix this; this
is more a question for those more knowledg
On Feb 1, 2008, at 12:47 PM, sagun shakya wrote:
Sebastien Roy wrote:
* 118-123: I would think that in 2008, most compilers can do a
better job at assigning register use than this (making every single
variable a "register" variable.) You don't have to fix this; this
is more a question
Alexander 'Leo' Bergolth wrote:
Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately, the same patch seems to cause some displacement of the
frames, starting with the first captured frame, when using the "any"
interface.
So by "the same patch" are you referring
Abeni Paolo wrote:
*) If pcap_loop is called with cnt=0 (ngrep erroneously does that), it
will busy-loop forever. pcap_read_linux_mmap doesn't handle that case,
it returns 0, which is asymmetric to pcap_read_linux's behavior, which
reads one packet.
I think there is a little confusion about th
Alexander 'Leo' Bergolth wrote:
Sorry, I wasn't aware of the ambiguity...
It's an obscure ambiguity, but I just wanted to make sure.
I've checked your typo fix in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Alexander 'Leo' Bergolth wrote:
Hi!
On 01/31/2008 02:39 PM, Abeni Paolo wrote:
on Thu 1/31/2008 10:37 AM Alexander 'Leo' Bergolth wrote:
I just gave your new linux mmap patch a try
thanks for the review :-)
Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately
Guy Harris wrote:
*However*, unless I'm missing something, a pointer to the payload after
the SLL header is being passed to the callback;
...
I'll try it out on my Ubuntu "machine"
That appears to have been the problem; I checked in a fix that made it
work,
Abeni Paolo wrote:
Any comments are as usual very welcome.
So far, I have it compiling and working on:
Mac OS X 10.4
Mac OS X 10.5
FreeBSD 7.0 RC1
OpenBSD 4.2
Ubuntu 7.10
where "working" includes an additional pcap_set_rfmon() call to turn on
moni
BTW, my original tests of the monitor mode changes didn't work on
FreeBSD or OpenBSD, because the adapter was added when I plugged it
into the USB bus, but wasn't automatically brought up. I had to do
"ifconfig zyd0 up" to make it work.
If libpcap can determine that an adapter isn't up, sh
It's 2008. Should we enable IPv6 support by default in libpcap and
tcpdump (as long as the OS supports IPv6 to a sufficient extent that we
can compile the support in), and let users do "--disable-ipv6" if, for
whatever reason, they don't want it?
-
This is the tcpdump-workers list.
Visit https
Gert Doering wrote:
tcpdump is not actually *doing* any IPv6.
It's doing IPv6 name resolution.
However, as tcpdump no longer depends on the OS to provide headers that
define the formats of packets, that might reduce the dependency on OS
IPv6 support.
(I can do tcpdump to look at "spannin
Carter Bullard wrote:
Are you going to make it so that the routines in inet.c, such as
add_addr_to_iflist()
and pcap_lookupnet() can work with IPv6 addresses?
add_addr_to_iflist() appears to work with IPv6 addresses on my OS X
10.4.11 machine, as pcap_findalldevs() finds the IPv6 addresses fo
Carter Bullard wrote:
I think the point is that you shouldn't have routines that are 'inherently'
limited to IPv4 addresses, if you support IPv6.
Removing pcap_lookupnet() would break source and binary compatibility.
I suppose libpcap 1.0 could, in theory, break both, so we could perhaps
get
Abeni Paolo wrote:
I thought that such things (pcap API to ask for supported parameters)
could be implemented adding dedicated fields into the pcap struct (on in
a pcap_t sub structure), which must be set by the platform specific
pcap_activate().
That would mean you couldn't ask for supported
On Feb 8, 2008, at 11:38 AM, Guillermo Hurtado wrote:
This is the first time I write to this list. I just read a post
about the
behavior of function pcap_lookupdev().
Now I wonder: what if I have two or more (2...N) Ethernet NICs
installed in
my computer and I want to retrieve the name of t
On Feb 7, 2008, at 4:42 PM, Hagen Paul Pfeifer wrote:
pcap_getnonblock_mmap() and pcap_setnonblock_mmap() declaration
differs from
prototype declaration and defines them !static. This patch fix this
issue.
Checked into the main and 1.0 branches.
-
This is the tcpdump-workers list.
Visit h
Luca Deri wrote:
is there any chance to see PF_RING support in libpcap source tree?
Please let me know if I can do something in order to push this process.
I'd sent a message to tcpdump-workers on 2008-01-24 with the subject
line "Re: [tcpdump-workers] Libpcap reentrancy and PF_RING patch", w
Paolo Abeni wrote:
On Mon, 2008-02-11 at 01:20 -0800, Guy Harris wrote:
What's the advantage of requiring that
pcap_get_monitor_mode_availability() be called after pcap_activate()?
This way all the platform/device dependent code can be placed into
pcap_activate(), elsewhere we have to
Paolo Abeni wrote:
Perhaps I'm missing the point, but I think a similar situation
currently happens in the pcap_findalldevs() function, which ultimately
calls pcap_open_live()/pcap_close() for each discovered device.
That's an implementation detail; if there were a way of determining
whether
Christian Stalp wrote:
And now the first weired thing: if I check my interface for ethernet
it passes, if I check for wlan it fails!
I infer from the name "ath0" that this is *BSD.
If so, then all 802.11 devices default to providing Ethernet headers,
for compatibility with applications that
On Feb 15, 2008, at 4:52 AM, Christian Stalp wrote:
But the result is the same. Its still the first four fields of my
MAC-address but the final two are still trash.
I.e., the first four octets of the source MAC address are valid and
have the correct values (i.e., they match the MAC address
On Feb 15, 2008, at 2:15 AM, Christian Stalp wrote:
I changed my capture-routine this way:
void packet_default(u_char *args, const struct pcap_pkthdr *header,
const u_char *packet)
{
char insertvalues[256];
memset (insertvalues, 0x0, 256 );
//struct ieee_802_11_heade
On Feb 8, 2008, at 2:20 PM, Eric wrote:
2. I've downloaded/compiled flex-2.5.34, bison-2.3, and
libpcap-0.9.8 [in /usr/local] beforehand.
3. When attempting to compile tcpdump-3.9.8 I get the following error:
==
/usr/local/lib/libpcap.a(pcap.o): In function
`pcap_datalink_name
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
It says, in a comment you added to configure.in:
+ # Due to a gcc bug (6619485), the default search path for 32-bit
+ # libraries does not inclu
On Feb 13, 2008, at 6:14 PM, sagun shakya wrote:
Updated webrev can be found at:
http://cr.opensolaris.org/~sagun/libpcap-review2/
Why did you add a
AC_CHECK_HEADERS(sys/bufmod.h)
check to configure.in after the check for libdlpi? It's checked for
later in the case statement if
sagun shakya wrote:
I agree, I'll add this to the configure script of tcpdump. This would
also be applicable for wireshark then?
Yes, and probably Snort and other apps using libpcap.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
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
sue?
Yes:
revision 1.291
date: 2007-10-26 00:44:56 +; author: guy; state: Exp; lines: +13 -1
Re-initialize the table of used registers, and the current register,
before compiling an expression; pcap_compile() can be called more than
once, and some registers can now be allocated and not freed in t
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
901 - 1000 of 2486 matches
Mail list logo
