kashif wrote:
I have configured my PC running RedHat Linux 9.0 into a router by
turning on the ip_forwarding facility of it. It got TWO LAN cards...and if i
run two instances of *pcap* one for each LAN card for capturing
packets, it works fineBut i intend writing an application wherein
i nee
On Apr 6, 2006, at 2:22 PM, J S wrote:
I am developing an active monitoring system, which implements pcap
filter.
What do you mean by "implements pcap filter"?
The requirement is to send probes with a high monitoring rate e.g.
40 msec
and the probe packets have data of 12 bytes. For each
Hannes Gredler wrote:
checked in - thanks for the submission - /hannes
On Wed, Jan 19, 2005 at 05:35:13PM -0800, Rick Jones wrote:
| A while back I think I posted something asking about what to do about TSO
| (large send) and how it generated "IP bad-len 0" output when tracing on a
| TSO-enab
Hannes Gredler wrote:
you may want to check the text2pcap utility
that comes along with ethereal for learning about
conversion to a libpcap readable format.
Or, alternatively, with newer versions of libpcap (those with
pcap_open_dead(), so you can write to a libpcap file without having a
lib
On Apr 7, 2006, at 10:08 AM, Rick Jones wrote:
As for checking against the normal MTU, does tcpdump/libpcap have
that information?
Only to the extent that it could infer that from the link-layer
type. (Jumbo frames might make that tricky.)
Does libpcap/tcpdump have any way of knowing th
On Apr 24, 2006, at 3:23 AM, Sumit wrote:
printf("packet time/caplen/len %u %u %u\n", header-
>ts, header->caplen, header->len);
You can't do that. "header->ts" is a structure, and you can't print
a structure with "%u". What that statement actually does is
implementation
On Apr 24, 2006, at 3:23 AM, Sumit wrote:
Main difference is extra 2 bytes at the first of pcaket. Also there
is not having proper destination H/W Addr; i.e. my machine's MAC,
in starting bytes of packet. Do I need to set something or call
some pcap routines?
One thing you need to do, if
On Apr 24, 2006, at 10:37 PM, Sumit wrote:
I submitted libpcap-0.9.4-1.i386.rpm but no-one care about it. Can
you tell me if maintainer interested on that part? I got a auto
reply about size of mail. Please send me some personal address to
send it to.
To whom did you submit it? And wha
On Apr 24, 2006, at 10:44 PM, [EMAIL PROTECTED] wrote:
So I want to add support for unix socket to Pcap library. As pcap uses
DLT_xxx for identifying the type of interface and Linux uses the ARP
hardware type.
In case of unix socket what value should be given, is there any value
already defined
On Apr 28, 2006, at 2:12 PM, Cove Schneider wrote:
As far as I can tell fwrite() will occasionally write short. I'm
assuming because my pipe is "backed up" and libpcap can't write
anymore data to it (though I would expect it to block in that case,
so I'm not really sure what's causing it t
the
duplicate-message dissector.)
Cove Schneider wrote:
Guy Harris wrote:
Either
1) the pipe is or other network connection is in non-blocking mode
(in which case it *won't* block in that case)
or
2) there's a bug in the OS on which you're running this.
I believe
Lan Qing wrote:
hello,
I read the fllowing words in the c header file
I.e., the header that came with your OS, not the header that comes with
tcpdump?
/* Internet address. */
typedef uint32_t in_addr_t;
struct in_addr
{
in_addr_t s_addr;
};"
the struct in_addr have only one variable
reduce the the filter string for performance.
4. Else, can some one provide with a logic to reduce the filter string (from
a lot of host address to a simple net address if possible).
With Regards,
Chris Guy.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Cove Schneider wrote:
Guy Harris wrote:
Either
1) the pipe is or other network connection is in non-blocking mode
(in which case it *won't* block in that case)
or
2) there's a bug in the OS on which you're running this.
I believe it's 1 here, the other end of
On May 18, 2006, at 9:18 PM, sandeep nitta wrote:
can anyone help me out with how a tcpdump -w command works.
I want to know what library functions are invoked if i use a -w
option and
the structures used.
It uses:
pcap_open_live() to open the capture device;
pcap_dump_op
Felipe Kellermann wrote:
> This fixes the problem to me. Does anyone know why 0x << (32 - 0)
> is resulting in 0x in mcode?
To quote the ANSI C89 standard, section 3.3.7 "Bitwise Shift Operators":
If the value of the right operand is negative or is greater than or
equal to th
Felipe Kellermann wrote:
> Thanks. I will look at the resulting assembly in the different toolchains
> and processos and systems and eventually discuss this subject with the GCC
> or binutils people.
I.e., suggesting that they standardize on a particular behavior for shifts
greater than the widt
axi wrote:
> My driver/card in monitor mode sends to libpcap a frame with FCS,
> when tcpdumps ( version 3.9.4 ) parsers i.e a valid Beacon Frame, it's
> identifies FCS part as a Tagged Parameter in a Management Body, and
> sometimes when pass TEST2 check, caused by that prints [|802.11] instead
>
On Jun 12, 2006, at 11:53 AM, [EMAIL PROTECTED] wrote:
I am trying to read file generated by 'tcpdump -r '
"-r", or "-w"? "tcpdump -r " reads the file in question
and prints the packets it reads. "tcpdump -w " captures
packets and writes them to a file in binary format.
I would real
On Jun 12, 2006, at 7:07 PM, [EMAIL PROTECTED] wrote:
The part I am confused about is where and when does ethernet comes
into picture. I got my program to print the header values, but I
was looking to know the type and everything I can find about the
ethernet frame wrapped in the packet.
On Jun 13, 2006, at 7:18 PM, [EMAIL PROTECTED] wrote:
I get a packet which is of type 802.1d at regular intervals.
I was eager to know the packet type of this particular packet.
I am catching this packet as unknown type.
I assume that's "802.1D", capital "D".
If so, they're probably Span
David Rosal wrote:
I've tried to use a class function member as a callback for pcap_loop(),
but the compiler complains that arguments don't match. The code is
something like this (I have simplified it):
...
Should I avoid C++ and use C instead (don't say that please...)
Should you
[EMAIL PROTECTED] wrote:
I wanted to access IP packet and then subsequently UDP/TCP/ICMP/IGMP
packet information. Are there any explicit function which I can call to
get information like version, IHL, source port, destination port, etc.
to get that information for each IP type of packet.
No
On Jun 26, 2006, at 12:03 PM, [EMAIL PROTECTED] wrote:
I am trying to disect ARP/RARP packet.
Basically I am looking for this information: Operation code,
Sender HW address, Sender Protocol address, Destination HW address
and Destination Protocol address.
Is there a direct way using pca
On Jun 24, 2006, at 10:50 PM, Richard Hansen wrote:
I have one thread that sits in pcap_loop() and another thread that
calls pcap_breakloop() when it is time to shut down. My code works
well on Windows (WinPcap 3.1).
Well, sort of. I suspect that pcap_breakloop() doesn't *immediately*
Fabian Schneider wrote:
I thought (and i have a programm running with this) that you can use the
to_ms value in pcap_open_live() to set such a timeout. The value won't be
interpreted by some OS'ses like FreeBSD or if you are using the
libpcap-mmap patch, resulting in a normal behaviour. But wi
Eloy A. Paris wrote:
So, according to a comment from Guy in the CVS log for pcap-bpf.c,
select() should work on BPF devices on Tiger.
It works as well as it does on older versions of other BSDs.
This means that you can do a select() on it, and, if the BPF buffer
fills up, the select() will
Eloy Paris wrote:
Wow, I feel like an idiot. Looks like I didn't do my homework well.
Further digging on the mailing list archive gave me the answer:
BIOCIMMEDIATE
Doing an ioctl() for BIOCIMMEDIATE on the file descriptor returned
by pcap_get_selectable_fd() completely fixes the problem.
It w
David Rosal wrote:
ip_off is an u_short, so byte order issues apply. Try this:
printf("%d|", ntohs(ippkt->ip_off));
...and then remember that the upper 3 bits of that 16-bit field are flags:
#define IP_RF 0x8000/* reserved fragment flag */
#define IP_DF 0x4000
Adam M. wrote:
This is probably a FAQ++, but I'm having trouble using Pcap for
savefiles that were captured from a loopback device.
There are 2 problems here:
1) In general, how is one supposed to determine what the layer-2
protocol is?
Call pcap_datalink() on the pcap_t. It'll indicate what
On Jul 28, 2006, at 12:51 PM, Harley Stenzel wrote:
Show that this happens when 2 threads use pcap_t at the same time:
libpcap is, for better or worse, not thread-safe, in the sense that
no locking is done on the pcap_t structure to prevent concurrent
accesses from stepping on each other,
Aaron Turner wrote:
Sorry if this is a little offtopic, but I'm in the process of ripping
out libnet from my code and replacing it with libpcap since it can now
inject frames. One thing I'm stuck on though is trying to figure out
a reliable, cross platform way to determine the MAC address of th
Naveen N Rao wrote:
I am trying to get packet transmission working using pcap_inject() on AIX
5.3. I haven't had any success using BPF and DLPI. With BPF, I get "send:
Error 0"
That means that the write() done to the BPF device returned -1 but
didn't set "errno" to a valid error value.
Give
[EMAIL PROTECTED] wrote:
when given a rule consisting of a set of sub rules to pcap, if a packet
matches the rule, how do I know which sub rule it matches?
libpcap will not tell you that. As far as it's concerned - and as far
as the kernel is concerned, on those platforms where the packet
tvfbfdb uyvy wrote:
I developing a tool for dumping all the data from a packet interference
engine into a log. I have undestood that in pcap_read_packet(), the
recvfrom function stores all the data from the socket (related to the
file descriptor specified) to a buffer,
Not on the computer o
On Aug 30, 2006, at 10:48 AM, [EMAIL PROTECTED] wrote:
I wish to use hostap (a driver for wireless cards) + libpcap +
tcpdump to
bring some extra details of the packets in the user space.
What sort of extra details?
I wish to know that how libpcap reads the packet from the kernel/
interfa
madhuresh wrote:
Yes you are right. I was mentioning about hostap-driver-0.4.7 which
works as a module with linux kernel.
(The linux-2.6.17.3 kernel has a drivers/net/wireless/hostap directory.
What's the difference between that driver - or any versions from later
Linux kernels - and the ho
[EMAIL PROTECTED] wrote:
For tcpdump, I am trying to find out where is CFG ( call flow graph
structure, which is used for further optimization ) generated? during
parsing stage or after the parsing stage?
*Currently*, the CFG is generated by pcap_parse() (and by a call to
gen_retblk()), whi
Bruce Keats wrote:
After digging into the issue, I have come up with a patch. The crux of the
problem is that the off_ll is added twice when generating the BPF code that
peeks into the LLC header.
Yes. The real problem was that the code was a bit confused about where
to add in off_ll.
I've
Guy Harris wrote:
I've checked into the main and x.9 branch (so if there's an 0.9.5
release, it'll be in that release; I don't know whether there will be
one or not) a change to fix up the addition of off_ll (by centralizing
it, and *not* adding it into other off_ value
abeni wrote:
An USB pseudo header is prepended to the captured URB to give
additional information on URB (type, sender, ecc.).
That pseudo-header is currently in a separate GPL'ed pcap-usb.h header:
1) The rest of libpcap is licensed under the Berkeley license, with
some of it under the fou
On Oct 2, 2006, at 2:31 AM, Paolo Abeni wrote:
I posted this mail a few days ago, but I can't see it in the mailing
list archive... Sorry for any duplicates...
I didn't see it either.
The USB pseudo headers are still in a separate file, must I move them
into pcap.h ?!?
Not necessarily.
On Oct 2, 2006, at 6:21 PM, ronnie sahlberg wrote:
No it is for "raw" usb frames with some additional infomation
added by
the capturing layer.
Some of these frames, those captured when talking to a memorystick,
will
likely contain SCSI CDBs and DATA frames in some layer above the
actu
Michael Richardson wrote:
"Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
>> The USB pseudo headers are still in a separate file, must I move
>> them into pcap.h ?!?
Guy> Not necessarily.
Guy> If we have a separate header, however, I&#
dean gaudet wrote:
i think you forgot to cvs add pcap/sll.h ... it's not there in cvs.
Fixed.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Paolo Abeni wrote:
It works. Or at least it seams to work :-). It probably needs more
testing, anyway I tried it with wireshark and grabbed the attached
capture files. The first is obtained plugging a mouse into the use port,
and the second unplugging it.
I don't see any attached capture files
Paolo Abeni wrote:
After a bit more testing I found some issues with current usb sniffing
code:
- the snaplen parameter is just ignored.
- the raw data received from usb port is partially corrupted.
The attached patch should fix both.
Checked in.
-
This is the tcpdump-workers list.
Visit htt
Paolo Abeni wrote:
The attached differential patch fix the compile issue introduced by me.
You can use it instead of revert
'ascii_conversion_and_snaplen_fix.patch' and apply
'ascii_conversion_and_snaplen_fix_v2.patch'.
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelma
Paolo Abeni wrote:
A binary interface for sniffing USB packets is coming, so we will soon
get packets with this header formatted following the standard. The
attached patch change the usb setup struct as the standard tell, it is
worthy ?
Yes. Checked in.
-
This is the tcpdump-workers list.
Vis
On Oct 11, 2006, at 11:03 AM, Brocha Strous wrote:
I have 2 different implementations. The problem is only with a very
small number of users so its not server-wide. Possibly related to a
specific firm-ware version of a Zyxel router - are there any known
in-compatibility between pcap and this ro
Paolo Abeni wrote:
The attached patch fix the parsing of setup data fields in current
implementation of usb_read_data.
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Oct 12, 2006, at 6:48 AM, Paolo Abeni wrote:
I'm working to add bluetooth/hci support (like hcidump) to libpcap,
Good!
can you please assign a new DLT value for bluetooth/hci ?
Does "like hcidump" mean the first byte of the data is a code for the
type of packet, i.e.:
1 - H
Paolo Abeni wrote:
Yes. I used my patched version of libpcap with wireshark and it was able
to dissect sniffed hci frames using current wireshark hci dissector[s].
Great!
It's DLT_BLUETOOTH_HCI_H4/LINKTYPE_BLUETOOTH_HCI_H4, with a value of 187.
-
This is the tcpdump-workers list.
Visit https:
Paolo Abeni wrote:
Very sorry, I forgot to add the attach in the previous mail. you can
find the lookupnet fix patch attached to this mail
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Paolo Abeni wrote:
The attached patch enables sniffing from bluetooth devices for the Linux
platform.
Checked in.
I added pcap-bt-linux.h and pcap-usb-linux.h headers and had
pcap-linux.c include them if PCAP_SUPPORT_{BT,USB} is defined and had
pcap-{bt,usb}-linux.c include them uncondition
Paolo Abeni wrote:
the attached patch fix an off by one in current usb sniffing code. It
also substitute the kernel-provided timestamp with gettimeofday. The
kernel provided timestamp use 32 bits to represent a struct timeval (8
bits for tv_sec and 24 for tv_usec), so it's content is quite
misle
On Oct 18, 2006, at 3:41 PM, Alexander Dupuy wrote:
You really want to use select() (or poll() if your operating system
doesn't support select()) instead of a CPU polling loop. You can
use pcap_get_selectable_fd() to get the underlying file descriptor
on a Unix system (won't work on Windo
Sebastien Raveau wrote:
I'm currently trying to pass the file descriptor of a live capture to another
process, so that I can have a very small (as in "auditable") privileged
process able to call pcap_open_live() on the one hand, and a big/fat/ugly/gui
process on the other hand running all the
madhuresh wrote:
I am just anxious to know that why we do filtering of packets at user
space and not at driver level (kernel space).
Because, on those OSes where filtering is done in user space, the OS and
drivers either don't have a filtering mechanism or don't have one that
uses BPF progra
On Oct 23, 2006, at 12:56 PM, madhuresh wrote:
Note, however, "in kernel space" doesn't necessarily mean "at the
driver level"; on Linux, the in-kernel filtering is done by "socket
filters" above the driver, and, even on BSD, although the driver
directly calls the BPF routine to supply a p
madhuresh wrote:
So the final question is "Is there any alternative way (consider
operating system to be linux) apart from BPF code for kernel level
filtering" ?
To my understanding there can be two possibilties:
1. A new interface (say XYZ0) where only filtered packets come from
driver/ker
Guy Harris wrote:
You forgot option 3:
3. Raise the limit on the maximum number of BPF instructions.
You're going to have to add stuff to, or change stuff in, the kernel to
implement this *anyway*, so you might as well just boost the maximum
number of BPF instructions and not ha
Eloy Paris wrote:
Guy,
On Wed, Oct 18, 2006 at 04:12:04PM -0700, Guy Harris wrote:
[...]
Note that in some systems with BPF (older versions of
{Free,Net,Open,Dragonfly}BSD, current versions of Mac OS X), select()
(and poll()) don't work correctly on BPF devices, and so you have to
Eloy Paris wrote:
However, I think the reason that I am not seeing any broken behavior is
because I use BIOCIMMEDIATE.
Right.
There you mentioned "It works around the problem by getting rid of the
timeout, so that as soon as a packet arrives the packet is made
available, rather than the BPF
abakash wrote:
I am new to libpcap and just want to know whether libpcap has got any
http support in it i.e. whether I can extract http header information
from any packet.
You can, if you choose, write code to extract HTTP header information
from any TCP segment captured by libpcap that cont
Hannes Gredler wrote:
you may want to check libpcap/savefile.c
[http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/savefile.c?rev=1.147]
to get a better understanding about the .pcap file format.
...and you might want to note that savefile.c is part of libpcap,
meaning that if you just want to
Maria Cruz wrote:
Hi, if a new protocol is introduced to libpcap is it necessary to
update 'gencode.c' for parsing?
You would have to add a case to the switch statement in init_linktype().
At minimum, it'd have to do
/*
* Currently, only raw "link[N:M]" filtering is supporte
On Nov 8, 2006, at 12:30 PM, Cruz Petagay wrote:
I would like to request a link- layer type value for WiMax (802.16).
The purpose is for support in wireshark/ethereal dissector.
I'll look at your mail about the layer at which this capture will be
done, and assign a type value and name to i
srinibas maharana wrote:
I am just trying to find out, whether it is possible
to use libnet/libpcap or, any thing simillar, for
redirecting an client application's data traffic meant
for a server application running on a separate
machine, to another application on the same machine
running the c
Maria Cruz wrote:
DLT_IEEE802_16_MAC_CPS is fine. Thanks. Will you also assign a value?
Yes - that's what this process is all about. I've assigned the value 188.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
I'll look at your mail about the layer at which this capture will be
done, and assign a type value and name to it.
Done, as per my other mail.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Paolo Abeni wrote:
A new binary interface for USB sniffing is making it's way into the
current kernel tree and I hope that will be available in the near
future. This will solve both problem and the relevant ABI has yet been
fixed, so I can produce the pcap code to use it. The new ABI will
provid
Michael Richardson wrote:
On an slightly off-topic note: is anyone aware of any USB-over-IP
protocols? Consider the case of the thin client that wants to have a
thumb drive inserted in the client show up on the "host".
A quick query to Sergey and Larry's servers found
http://www.digi
On Nov 30, 2006, at 1:08 PM, Aaron Turner wrote:
I guess I can understand why libpcap takes the min of snaplen &
caplen, but it would be nice if libpcap returned the actual captured
data rather then truncating it.
Unfortunately, I don't know where or how these pcap files were
generated, so I d
On Dec 4, 2006, at 2:41 PM, Gianluca Varenni wrote:
- Original Message - From: "Harley Stenzel" <[EMAIL PROTECTED]
>
It certainly does, but it expired more than 2 years ago. Is it
still active?
Although the draft expired 2 yrs ago, and I released some update to
the NTAR code ba
Paolo Abeni wrote:
- I'm not able to take advantage of the memory mapped access: the kernel
prepend to each event an header that is quite different form the libpcap
pcap_usb_header. To keep thinks working I need to modify 'in-place' this
header (but this requires write access to the memory mappe
Jan Allman wrote:
I'm using Ethereal and am confused about the SNMP dump. The field
sizes don't match the specification (RFC 1157).
Where in RFC 1157 does it specify what the field sizes should be?
For example:
E.g.
The 'Version' field should be 4 bytes but its dump is 3 bytes: 02 01 00
David Lopez wrote:
I'm developing a small sniffer for my project. I'm using libpcap
It appears, from your program, that you're using WinPcap (the Windows
port of libpcap).
Are you doing this on Windows (in which case you're using WinPcap) or
on some other OS (in which case you're using libpca
Paolo Abeni wrote:
To access the binary api, some device files have to be accessed. In the
patch the path for this devices is hard-coded, but the effective
location may change depending on the linux distribution.
So the driver that supports the binary API doesn't hard-code the
location of the
On Dec 17, 2006, at 2:18 AM, Paolo Abeni wrote:
this is an updated version of the patch to enable using the new usb
sniffing infrastructure under linux. It retain and clean up a bit the
existing code using the kernel text interface.
The main change from the previous post is an autoconf test fo
[EMAIL PROTECTED] wrote:
(See attached file: mtp2_filtering.tar.gz)
There doesn't seem to be an attachment to your message; the headers on
your message include:
X-Alcanet-MTA-scanned-and-authorized: yes
X-Content-Discarded: application/octet-stream
Does your corporate mail
[EMAIL PROTECTED] wrote:
Well, I do not understand why the attachment was discarded ?
Maybe the policy changed in the same time my email address ?
Anyway, I have renamed the file Tar dot gz file and will send it again as
attachment.
That succeeded. Choosing a different extension probably fool
[EMAIL PROTECTED] wrote:
Well, I do not understand why the attachment was discarded ?
Maybe the policy changed in the same time my email address ?
Anyway, I have renamed the file Tar dot gz file and will send it again as
attachment.
(See attached file: mtp2_filtering.archivegz)
That message,
[EMAIL PROTECTED] wrote:
I think the patch was discarded again in my last mail, so I post again but
in full text mode.
Sorry for the inconvenience..
(See attached file: scanner.l.diff)(See attached file: gencode.c.diff)(See
attached file: gencode.h.diff)(See attached file: grammar.y.diff)
Nop
[EMAIL PROTECTED] wrote:
Here is a short patch to implement filtering for MTP2 frames on SS7.
You can now use "fisu", "lsu", or "msu" to filter the MTP2 messages at
libpcap level.
In most of the case, the filter to use will be "!fisu", to have only the
significants frames.
I checked it in (one
ness wrote:
Below are a few interesting snippets of my code pertaining to libpcap.
All of the code is running on the main thread. Tcpdump and my
implementation both ran on an Airport Extreme card with WEP, but I doubt
that serves any relevance.
It probably isn't of direct relevance, but it a
Jonathan Gruenhut wrote:
This behavior is not unique to my own application; I get the same
behavior simply using tcpdump (version aix3.8 with libpcap version aix0.8).
So is that the tcpdump that comes with AIX and the libpcap that comes
with AIX?
If not, could you try it with the tcpdump th
Abeni Paolo wrote:
Most notably the byte alignment of header contained in each usb
'packet' is enforced to be little endian (currently is in host byte
order and this give some issue). This requires to disable memory mapped
access.
Is there a significant performance improvement from memory-mapp
Kevin Steves wrote:
The following patch fixes a bug in print-bootp.c. It will print an
extra "\n\t " when the last line contains 4 options. It is also
simpler in general and eliminates the need for a first variable.
Also contains some formatting and whitespace cleanup.
Checked into the m
Kevin Steves wrote:
The following patch does the following:
0) use TTEST/TCHECK macros vs. snapend comparisons
1) when -vvv display PAD and END options
(multiple PAD options are summarized)
2) change a trunc string from bootp to rfc1048 because I think that is
what is intended (matches tru
Abeni Paolo wrote:
the attached patch fix a format string error present into the bluetooth support
for linux.
The message involved is an error message, so the issue don't rise too often.
Checked in.
p.s. why don't add "-Wall" to the compiler options? it will help to find such
error.
Not
Kevin Steves wrote:
0) don't print spaces in [ flags ]
1) some whitespace cleanup in that area
Checked in to the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Abeni Paolo wrote:
1) the host reading a capture file can determine the byte order of the
host on which the capture was done,
I did not know this. Can you plase explain me how ?
The file header in a libpcap file starts with a magic number to indicate
that it's a libpcap file; the magic numb
Kevin Steves wrote:
this eliminates extra leading space for DNS dissector.
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Hannes Gredler wrote:
ahh now i get you ... the ttl %3u change was introduced _before_
we decided to print the ID-field ... and this made multiline
outputs more readable ...
checked in your fix into head.
Should it also go into the x.9 branch?
-
This is the tcpdump-workers list.
Visit https://
Abeni Paolo wrote:
the attached patch cleanup the usb_platform_finddevs(), removing the
dependency from debugfs. There are also some other minor cleanup in the
pcap-usb-linux.c file (unused variables removed and indentation fix).
Checked in.
I plan to post the aligment fix for usb header in
[EMAIL PROTECTED] wrote:
I need to capture and decode SSL traffic. Does tcpdump support this?
Tcpdump supports capturing *all* network traffic; if it captures and
saves packets to a file, the packet contents are just a big bucket of
bytes. Note that its default "snapshot length" is 68 byte
Abeni Paolo wrote:
The patch contained in the previous post does conatain an offset
error while accessing the linux usb header struct. The one attached
here should fix the issue. Please give it a review, since this sort
of thing is a bit tricky.
Checked in.
I was tempted by implementing and
Kevin Steves wrote:
I started looking at this because the minimum length check was
off by one.
0) fix off by one (4 vs. 3)
1) print flag bits
2) print rcode fields if either is non-zero
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/
On Jan 30, 2007, at 2:17 AM, [EMAIL PROTECTED] wrote:
I wrote a patch to avoid calling this function if the support for
IPV6 is
not present.
Checked in (but without the change to include ip6.h if the support
*is* present; it's not necessary).
-
This is the tcpdump-workers list.
Visit htt
601 - 700 of 2513 matches
Mail list logo
