On Jan 30, 2007, at 4:50 AM, [EMAIL PROTECTED] wrote:
Here is a patch for the libpcap interface with Endace DAG boards.
It should solve the following errors, when you are running Wireshark.
Checked in to the main and x.9 branches, with some additional cleanup
of the code that allocates and
On Jan 30, 2007, at 2:28 AM, [EMAIL PROTECTED] wrote:
I have a systematical crash at tcpdump startup, when I am using
libpcap
(2007-01-30)
I just add a test to check if the USB bus directory is present in
pcap-usb-linux.c, and it
seems to solve the problem.
Checked in.
-
This is the tcpdump
Adelmo Silva wrote:
Jin YunYe wrote:
On 2/2/07, Adelmo Silva <[EMAIL PROTECTED]> wrote:
Hello,
I have a error:
debian:/home/adelmojs/MONOGRAFIA# gcc teste1.c -lpcap -o teste1
teste1.c: In function 'SNIFFER':
teste1.c:294: warning: passing argument 2 of 'strcat' makes pointer from
integer witho
[EMAIL PROTECTED] wrote:
Very minor patch to print basic info about a few more Cisco LAN
protocols. See documentation of the PID values at for instance
http://www.cisco.com/en/US/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml#pre4
Checked into the main and x.9 branches.
[EMAIL PROTECTED] wrote:
Additionally, could you replace the word LSU by LSSU in gencode.c,
gencode.h, grammar.y and scanner.l.
This is the exact term to use for MTP2 messages.
Checked into the main and x.9 branches (with "lsu" supported as an alias
for "lssu", for backwards compatibility).
On Feb 8, 2007, at 1:22 PM, Stephen Donnelly wrote:
As a question to the community in general, is it true that the link
layer checksum is not normally included in libpcap records,
No.
For example, sometimes a frame in a DLT_EN10MB capture might have the
CRC, and other times it might not.
[EMAIL PROTECTED] wrote:
As requested few days before, I would like to use a new DLT to distinguish
between MTP2 without FCS (the current DLT_MTP2) and MTP2 with FCS.
Or perhaps the link type value in the file header should be interpreted
as having bitfields, with the lower 16 bits being the
Jon Steel wrote:
I have found a potential bug in libpcap on OpenBSD and likely FreeBSD as
well. If you simultaneously open several programs that open pcap
connections, you can cause the system to lose track of some of its
BPF's. When you close all the pcap connections some of the BPF's may
repor
Guy Harris wrote:
I can't reproduce this on OS X 10.4 - I get
$ sudo ./bpfMaker.pl en1
BPF's at startup:0
BPF's upon ending:0
...with a version of bpftest.c fixed so that, if pcap_open_live() fails,
it returns before calling pcap_loop() (otherwise
Adelmo Silva wrote:
But, if I wrote:
strcat(string1, &ips1[i]);
Another error happen:
teste1.c:294: error: incompatible types in assignment
So, on line 294 of testel.c, did you write
strcat(string1, &ips1[i]);
or did you write
string1 = strcat(string1, &ips1[i]);
I suspect
Jon Steel wrote:
I did some more digging and I think Ive narrowed the problem down a bit
more. It does appear to be a kernel issue. pcaps off the hook for today.
For those interested, the problem occurs for the following reasons: When
you call open() on OpenBSD it does not lock the file unless y
maneeshs wrote:
There seems to be a race condition in the above code, the check for the
descriptor being free and the call to D_GET to mark the descriptor as
being used is not atomic. So two closely spaced calls to bpfopen could
cause bpf to use the same device twice ?
Yes, if, in OpenBSD, e
(the -request address for a mailing list is for requests to be added
to or removed from a mailing list; it is not for messages sent to the
list itself)
On Mar 6, 2007, at 5:36 PM, ARAMBULO, Norman R. wrote:
Is the ethernet size always equal to 14 bytes?
The lowest-layer Ethernet header is
Albert Chin wrote:
Is CVE-2007-1218 applicable to tcpdump 3.9.4? Doesn't seem so as the
line in the following patch was added after 3.9.4:
The problem in 3.9.5 was that the line was wrong.
The problem in 3.9.4 and before was that the line was *absent*.
The check makes sure that the amount of
Florian Weimer wrote:
Thanks for the clarification. Have you already requested a new CVE
name?
Is one needed? The page at
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1218
says
Off-by-one buffer overflow in the parse_elements function in the 802.11
printer code (print-802_11.c)
Aaron Turner wrote:
notice the addtional 14 byes in the wireshark decode: "G SRC='http://";
When you say "same packet", do you mean that you ran "tcpdump -XX" on a
capture file, and ran Wireshark on the same capture file, and got the
"packet dump example from tcpdump -XX" output from tcpdump
Aaron Turner wrote:
That's an excellent question. The original pcap file is over 3 years
old, and honestly I don't remember. My guess is that the packets were
most likely captured using tcpdump using the default snaplen on a
RedHat Linux box since that was my main development environment at th
Aaron Turner wrote:
Not sure I follow the above. What value are you talking about here...
the file snaplen?
Yes.
Not sure what errors you're talking about here.
People should always compare the packet caplen/len to determine if the
packet was truncated, not the file snaplen.
It's not a qu
On Mar 21, 2007, at 2:26 PM, Greg Hellings wrote:
While stumbling through the tcpdump code it looks to me like tcpdump
uses its own methods (in the print-*.c files) for displaying output to
the screen,
Yes. That is as intended. libpcap is a library for capturing and
sending traffic, and r
On Mar 21, 2007, at 6:07 PM, Greg Hellings wrote:
In my experience libpcap lacks an application-layer parser.
Correct. Parsing the packet at all is left up to the program using
libpcap or the library processing the packets that libpcap generates,
as different applications have different
On Mar 23, 2007, at 3:35 PM, Luis Martin Garcia wrote:
Is there any way, using libpcap or not, to get the IP of a network
interface in a portable and easy way?
With newer versions of libpcap/WinPcap, you could try using
pcap_findalldevs() and look for the interface in question on the list
Jung-uk Kim wrote:
FreeBSD has added PCAP_D_OUT support for pcap_setdirection():
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Aaron Turner wrote:
Honestly, I can't imagine why the snaplen is interesting other then
for properly sizing the packet data buffer,
It might be useful to use as evidence if somebody asks why a capture has
only partial packets in it.
Well the real issue IMHO is the buggy RH hacked libpcap.
[EMAIL PROTECTED] wrote:
Please tcpdump, do not end, but run over damaged packets (move from
current position in cap file byte by byte) from cap file until You find
good header and packet,
Define "good".
The code *could* skip forward until it finds something that appears to
have a caplen <=
Richard Stearn wrote:
+ case DLT_AX25:
+ /*
+* Currently, only raw "link[N:M]" filtering is supported.
+*/
+ off_linktype = -1; /* variable, min 15, max 71 steps of 7
*/
+ off_nl = -1;/* variable, m
Juergen Schimmer wrote:
I would like to request a new DLT value for 802.15.4 Low rate wireless
personal area networks.
I am currently working on an project using 802.15.4 and would like to
use libpcap.
So a packet in a capture file would begin with the 2-octet Frame Control
field, as per Figu
Jon Smirl wrote:
Attached is some clean up for libpcap support of usbmon on Linux.
You might want to send it as "diff -c" or "diff -u" output, in case
changes are made to those files before the patch is applied (as has
already happened - I added RCS IDs to some files that lacked them,
includ
Richard Stearn wrote:
What the implementors of AX.25 on Linux have done is to hand an KISS
packet rather than a pure AX.25 packet to the protocol stack. This
probably was to accomodate the existing base of hardware where packets
were delivered to the system via an async serial port and the leng
Guy Harris wrote:
Is KISS a standard independent of Linux?
Apparently:
http://www.ax25.net/kiss.htm
so DLT_AX25_KISS is, I think, the right way to go here.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Juergen Schimmer wrote:
Yes. In difference t the 802.15.4-2006 spec all Address fields are at
the maximum
size ( This is done in the device driver for better handling in the
upper layers )
In other words, the packets are *NOT* 802.15.4-2006 packets as they
appear on the air, but have had the
Juergen Schimmer wrote:
2007/4/2, Guy Harris <[EMAIL PROTECTED]>:
In other words, the packets are *NOT* 802.15.4-2006 packets as they
appear on the air, but have had the address fields padded?
Yes
Is this on Linux?
Yes it is on Linux. ( X86 and uClinunx ARM ). At the Moment i try
Richard Stearn wrote:
Adding DLT_AX25_KISS is the obvious way to go with the exception that Linux
identifies AX.25 in KISS packets as DLT_AX25 (protocol 3).
"Identifies" in what sense?
I don't see any use of DLT_AX25 in the 2.6.20.4 kernel. It appears to
use ARPHRD_AX25 as the arphrd value
Aaron Turner wrote:
Long story short, I just figured out that both pcap_inject() and
pcap_sendpacket() have the same problem (a bug in my code was hiding
the error returned by pcap_sendpacket()).
However the bug doesn't seem to affect directly sending using BPF
directly or using Libnet (which a
Aaron Turner wrote:
Looks like I'll need to see if my contacts @ Apple can get this bug
fixed.
Do you have an ADC account? If so, file a bug (and send me the bug number).
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Alexander Dupuy wrote:
The fix is easy:
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Jon Steel wrote:
It needs to be changed to:
#ifdef __OpenBSD__
#define DLT_LOOP12
#else
#define DLT_LOOP108
#endif
Done, in both the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Mikko Saarnivala wrote:
The first problem is that I noticed that the DLT_IEEE802_15_4_LINUX was
just assigned but it is for these packets which have address fields
padded. Should I request for a new DLT value to be assigned?
If the headers you'll be supplied are completely unmodified 802.15.4
Quan Doan wrote:
Hi Aaron,
Thank you. But the thing is I would like to monitor those traffic from our
LAN, and I only could capture those packets on my box, then I will transfer
all packets from my box to my monitoring server.
With Ethereal I can not monitor all packets in real-time.
In your or
Quan Doan wrote:
The command is useful for real-time captured packets? It means I had
captured those packets from my LAN and transfer over internet to a remote
server.
How did you transfer those files?
In this server, I have all captured packets. The transfer is
real-time.
"Real-time" in w
Aaron Turner wrote:
FYI, I've opened another ticket with apple (Bug ID# 5152213) regarding
pcap_findalldevs(). Short story is that calling pcap_findalldevs()
causes the builtin wifi on my MacBook Pro (10.4.9) to disassociate
from the AP. Very annoying, especially since you needn't be root to
ha
Joerg Mayer wrote:
Well, it's not a bug per se, but I really think that the capture syntax
manpage should be part of libpcap and not of tcpdump. I know of a few
systems that have wireshark installed but not tcpdump. Also, it is
possible to build tcpdump with older versions of libpcap where the
c
Charles Clancy wrote:
1. Allocate another DLT specifically for Radiotap+WiMAX
2. Extend the Radiotap header to indicate what protocol it's encapsulating
3. Don't use Radiotap, and develop something else
What's the group's thoughts on these options, and which would be most
preferred? #1 seems
Charles Clancy wrote:
... then I'd like to request allocation of a DLT for Radiotap with
802.16-CPS.
OK, I've added DLT_IEEE802_16_MAC_CPS_RADIO and
LINKTYPE_IEEE802_16_MAC_CPS_RADIO, with the value 193.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Luis Martin Garcia wrote:
Well, you can open your pcap file with Wireshark (ethereal), select
the packets you want using the filter and saving them using the
standard "save as" option.
He doesn't want packets saved as is, he wants *transformed* versions of
the packets written to the new file:
On May 16, 2007, at 2:57 PM, Jesse Norell wrote:
I hope this is an appropriate question for this group. I'm with a
group (WISPA) working on developing a standard for delivery of data to
meet the CALEA law requirements.
Why is the Women's International Squash Players Association working on
On May 18, 2007, at 7:09 AM, Alexandros Karypidis wrote:
I am writing a program that is intended to monitor the requests made
to
a server from various clients. I am using libpcap to capture all
packets directed to the server's IP and need to parse the _payload_ of
the TCP stream (i.e. isolate
Łukasz Strzałkowski wrote:
Tcpdump collects much less packets then kismet and all of them are from
my laptop and my Access Point.
Please someone explain me why it is so if tcpdump reads the same
wireless interface in this router as kismet drone?
Probably because tcpdump isn't putting the inte
On May 23, 2007, at 2:34 PM, kevin brintnall wrote:
I would like to add a feature to tcpdump/pcap to only capture 1/S
packets
for some positive integer S. For example, this would be useful for
traffic analysis on DNS servers where it's not feasible or desirable
to
capture every single pac
Anton Yuzhaninov wrote:
Hello.
When libpcap build with -DINET6 pcap_compile() generates strange pbf
code with DLT_RAW
cap_compile_nopcap(65535, DLT_RAW, &bp, "udp", 1, 0)
generates this code:
# (000) ld #0x0
{ code=0 jt=0 jf=0 k=0 }
# (001) ldb [6]
{ code=48 jt=0 jf=0 k=6 }
# (002)
On May 30, 2007, at 1:24 PM, Anton Yuzhaninov wrote:
It seems better. Which libpcap version was used to produce this bpf
code?
No released version was used. The version was used was the version
built from the source I'd just checked in.
This is checked into the main and x.9 branches.
Mikko Saarnivala wrote:
Referring to the conversation quoted above, I request for a DLT number
for IEEE 802.15.4 compliant implementation.
I've added DLT_IEEE802_15_4, with the value 195.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Jun 13, 2007, at 9:32 AM, Jonathan Gruenhut wrote:
To be honest, at this point I’m totally mystified. My (naive)
understanding of shared objects in Linux was that as long as the
major version number was the same, the loader should look up
whatever is present on the system.
That's how
Max Laier wrote:
[this is not necessarily the right mailinglist for this question, but ...]
Well, Wireshark has separate wireshark-dev and wireshark-users lists,
but tcpdump-workers is really the union of "tcpdump-users",
"tcpdump-dev", "libpcap-users" ("users" in the sense of people writing
Max Laier wrote:
the attached makes libpcap and tcpdump use pfvar.h/if_pflog.h from the
host system (if available) - which is what most people will want[*].
What most people want, I think, is to be able to capture on the pflog
interface and read pflog files, regardless of how that happens; if
Peter Volkov wrote:
We received report on security issue in tcpdump:
http://bugs.gentoo.org/184815
Could anybody review fix and comment and apply in CVS? Thanks.
I reviewed the fix - it seemed a bit cleaner to have it continue
processing the TLVs, without adding to the string, if the string
Fulko Hew wrote:
I am formally requesting a new DLT value to support capture traffic
from my companies
So that'd be SITA:
http://www.sita.aero/default.htm
LAN/WAN router/protocol converter device.
Since this device supports WAN protocols, this new DLT will be
used to provide/indicat
Fulko Hew wrote:
a given capture will only ever have a single protocol within it,
but since the header is common for all protocols, I thought it was
better to
ask for a single DLT instead rather than one DLT per protocol.
Not necessarily - DLTs are cheap, and Wireshark already has, for
exam
Fulko Hew wrote:
So in the end... I think I'd rather continue persuing this single DLT
approach
where I can embed status/signalling stuff into a single dissector
IE. Have a pcap with DLT_ACN_WAN and dissectors for:
ACN_WAN (that handles signal/status info and then dispatches to:)
Frame
Fulko Hew wrote:
Well, I looked at it, and it sounds like a good idea, but it is
relatively heavy
weight (I only need to transport 4 bytes, and PPI has 8 bytes of overhead
(200% in my case) So I'm going to graciously decline and still ask for
my own DLT called 'DLT_SITA'.
(This also leave my
Fulko Hew wrote:
Well, I looked at it, and it sounds like a good idea, but it is
relatively heavy
weight (I only need to transport 4 bytes, and PPI has 8 bytes of overhead
(200% in my case) So I'm going to graciously decline and still ask for
my own DLT called 'DLT_SITA'.
OK, I've assigned y
Francois-Xavier Le Bail wrote:
I have an error compiling print-bgp.c if the support
for IPV6 is disable.
[...]
print-bgp.o(.text+0x26d): In function
`bgp_vpn_ip_print':
: undefined reference to `ip6addr_string'
[...]
Here is a patch to solve it.
Checked in.
-
This is the tcpdump-workers list.
Francois-Xavier Le Bail wrote:
Hi,
I try to build tcpdump-current (tcpdump-2007.07.20) and have these errors (no
problem with build of v3.9.5) :
System : x86 - gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
---
gcc -O2 -DHAVE
Francois-Xavier Le Bail wrote:
The following patch decode DHCP option 121.
Checked into the main and x.9 branches, with some changes (along with
some other fixes to option parsing).
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Nick Chorley wrote:
I'm using libpcap in programs I'm writing and I already have saved capture
files. I've seen many examples of using pcap_compile() and pcap_setfilter()
for capturing live packets, but none for use with offline files. The last
argument to pcap_compile() seems to be an IP addres
On Jul 25, 2007, at 1:57 PM, Stephen Donnelly wrote:
Florent Drouin from Alcatel-Lucent has been working on improving the
ERF
support in Wireshark. As part of this work we would like to request a
new DLT (DLT_ERF) which would encapsulate a single ERF record of any
ERF
type. DLT_ERF would b
On Jul 31, 2007, at 7:43 PM, Phil Mulholland wrote:
I'd like to request a new DLT value for our internal header format.
We have a patched version of libpcap that can capture packets from
our custom board. The
board can optionally attach it's own header to the packets, before
the Ethernet h
On Aug 6, 2007, at 1:59 PM, Gianluca Varenni wrote:
I agree with you. The server is either really slow or completely down.
Router problem. It's back.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Toeung, Chanthy wrote:
I'm doing a project on creating a plugins of packet IPMB ( with I2C
interface ) in Wireshark.
Now i need a specific DLT code for this packet so that i can put my
code in Open Source of Wirshark. Can you please assign me one number ?
So presumably the first byte of the p
On Aug 10, 2007, at 12:28 PM, Toeung, Chanthy wrote:
I need a specific DLT_ value for IPMB protocol. Does anyone know who
should i write the email too?
[EMAIL PROTECTED]
See the responses that were sent to your previous request for this.
And make sure you subscribe to the list; replies are
TJ wrote:
I'm not sure if these leaks and losses are related to the SIGSEGV but
they certainly ought to be cleared up.
Yes, they should, and here's how you do it:
In your program, replace
pcap_if_t *this_dev;
pcap_if_t **alldevsp = &this_dev;
with
pcap_if_t *alldevs
Phil Mulholland wrote:
Sure. The header is used to multiplex PCI frames and Ethernet frames
onto a custom processor interface. Our libpcap patch captures from this
interface. It looks like:
OK, that's a bit specialized, so it probably won't provoke any major
pcap-NG, tcpdump, Wireshark, etc.
[EMAIL PROTECTED] wrote:
There is need to assign DLT_LAPB value for capturing of the X.25 LAPB
traffic and decoding it in the WireShark Protocol Analyzer.
So would the packet data in a DLT_LAPB capture start with the address
field of the LAPB header, followed by the Control field, followed by
Toeung, Chanthy wrote:
I'm doing a project on creating a plugins of packet IPMB ( with I2C
interface ) in Wireshark.
Now i need a specific DLT code for this packet so that i can put my
code in Open Source of Wirshark. Can you please assign me one number ?
So presumably the first byte of the p
On Aug 13, 2007, at 11:45 AM, Toeung, Chanthy wrote:
So presumably the first byte of the packet data will be the slave
address, followed by the netFn and LUN, followed by the checksum,
etc.?
yes. It is correct.
OK, DLT_IPMB has been assigned the value 199.
Capture type, or DLT_ type?
Toeung, Chanthy wrote:
Does the USB captured mode work in Wireshark?
Yes, if your machine is running Linux with a sufficiently-recent kernel,
and Wireshark is using a top-of-tree version of libpcap. (I'm not sure
which version of the kernel is required.)
I doubt any distributions use the t
[EMAIL PROTECTED] wrote:
2Q: Or would it also contain an extra flag to
indicate whether the packet is a DTE->DCE or DCE->DTE packet?
2A: LAPB contains direction ( DCE to DTE or vice versa) encoded in the
Address byte.
Actually, what X.25 (10/96) says is:
Frames containing commands transf
Toeung, Chanthy wrote:
One more question, so what is the value of WTAP_ENCAP_IPMB that i should use
for my dissector?
The next value after the last one in wiretap/wtap.h. You will have to
add that to your version of wiretap/wtap.h, and modify the IPMI
dissector to handle that value.
Don't
Toeung, Chanthy wrote:
NOTE: WTAP_ENCAP_ values have no relation to the DLT_ values.
But when i use text2pcap to create pcap format, i need the DLT value,
It's 199, as per my earlier mail.
So beside this, where should i go to modify the new DLT_IPMB that you have just
assigned ?
You d
[EMAIL PROTECTED] wrote:
Here is possible solution to resolve DCE/DTE origin of a LAPB packet.
Wireshark libpcap.h has the struct pcaprec_ss990915_hdr, which has
ifindex field ( the interface on which packet came in ). During
capturing phase FROM_DCE or FROM_DTE will be stored into ifindex fie
Mark Bednarczyk wrote:
Can someone explain to me the difference between these two calls,
pcap_sendpacket vs. pcap_inject, introducted in 0.8.3?
The difference is that pcap_sendpacket() returns 0 on success and
pcap_inject() returns the number of bytes written on success.
From what I could
Fulko Hew wrote:
I am about to provide a patchset for supporting my newly added DLT type.
Since my changes also involve a minor change to 'configure.in', is it my
responsibility to provide patches 'configure' as well?
No.
or does someone
else run the appropriate utilities (aclocal; autoconf;
Saikiran Madugula wrote:
autoheader and autoconf should be sufficient ?
So is autoreconf, and it's 9 keystrokes fewer. :-)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Fulko Hew wrote:
Attached is the file that contains the patches to libpcap to support
DLT_SITA.
1) Files added to INSTALL.txt also need to be added to FILES.
2) the pcap-sita.html file says
Note: This document was derived from 'pcap.3' and is revision
controlled as part of the libpcap CVS.
Francois-Xavier Le Bail wrote:
The following patch decode DHCP option 249 (Classless
Static Route Microsoft) used by some Microsoft
systems. Same decoding as option 121 (RFC 3442).
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to un
Saikiran Madugula wrote:
I am a newbie too but I have following suggestions, although it always
tough
to suggest anything with out looking at source code. Did you make the
following changes to handle your interface correctly ?
pcap_lookup net, pcap_open_live and xxx_platform_finddevs.
Have yo
Audet, Jean-Michel wrote:
My problem is when I am starting the capture. My function close is
called then the find device loop starts, all the device (including
Ethernet, lo, ...) are re-open than close and is stuck in a loop. Than
I got a message from Wireshark that the process just died.
Wh
On Aug 29, 2007, at 9:32 PM, [EMAIL PROTECTED] wrote:
when build tcpdump, how to find all the FEATUREs when i want to use
./configure --disable-FEATURE,for example,to disable use openssl/
evp.h,
./configure --disable-evp which is do not work!
If you mean "how do I find all the features that
Fulko Hew wrote:
On 8/21/07, Guy Harris <[EMAIL PROTECTED]> wrote:
1) Files added to INSTALL.txt also need to be added to FILES.
Opps, sorry, I forgot about that file (I thought I caught them all).
Do you want me to submit a new patch file with that added?
If you make any other chang
[EMAIL PROTECTED] wrote:
OK, I see. Actually, I am using cross complie, so the openssl/evp.h is
found in /usr/include does not mean that I want this feature. @[EMAIL PROTECTED] I have
to backup evp.h first and then run configure. :-)
Then it sounds as if the configure script needs to check di
On Sep 4, 2007, at 2:49 AM, Varuna De Silva wrote:
We as a project try to build an SS7 analyzer which will port data
through
the USB bus.
For this purpose, We have used an USB IC from FTDI which do this job
with
their custom
driver. What the driver does is, it will write the data in to the
Alex Still wrote:
We're using tcpdump to try to diagnose an NFS performance problem.
We're seeing a lot of these :
[..]
16:01:19.890794 IP nfs_server.nfs > client_46.1205729087: reply ERR 1448
16:01:19.890831 IP nfs_server.nfs > client_46.3664003007: reply ERR 1448
[..]
That seems to be an RPC
Saikiran Madugula wrote:
I ran into this problem when I was trying to compile libpcap with a
package which has support for a custom interface in Linux. I get a
warning message about redefining ETHERMTU while compiling that package
as the package uses net/ethernet.h.
Do you get a warning messa
On Sep 5, 2007, at 2:17 PM, Saikiran Madugula wrote:
Yes, I get warning when gencode.c gets compiled with the custom
package.
(ofcourse standalone libpcap compiles fine).
gcc -O2 -I. -I -
DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -D -fPIC -
DPIC -c ./gencode.c
./gencode.c:87:1: war
On Sep 3, 2007, at 1:22 PM, Max Laier wrote:
Sorry for dropping the ball on this one. Please see attached for the
updated diffs. After this "pf.h" can be removed from the sources as
it
is no longer referenced.
Checked in, with pf.h nuked in both libpcap and tcpdump, FILES and
INSTALL/I
Gianluca Varenni wrote:
> After a quick compilation test, libpcap compiles ok (albeit with some new
> warnings popping out from VC6).
>
> tcpdump (0.9.x branch) has some problems, instead:
>
> - print-rsvp.c doesn't compile as it's not strictly C
I've checked in a fix (0.9 and main branch).
> - p
On Aug 14, 2007, at 11:21 AM, Chris Larson wrote:
The following fixes a tiny bug in the sctp printing which cut off the
last byte of the data in a DATA chunk. Seems like a copy/paste error,
as just above this is a check of the chunk size, and sctp requires a
data chunk to have at least -1- dat
On Aug 7, 2007, at 6:04 AM, Pekka Savola wrote:
In tcpdump 3.9.7 (Fedora 7) but seeing the same on FreeBSD, I
noticed that on a similarly generated TCP packet, IPv4 output
differs from IPv6 in that "length" in v4 includes the IP header
length, but in v6 it does not.
In the protocol speci
On Sep 13, 2007, at 6:26 AM, Ken Bantoft wrote:
On Thu, 13 Sep 2007, Abeni Paolo wrote:
on Thu 9/13/2007 12:51 AM Ken Bantoft wrote:
Just a heads up - we're releasing 3.9.8 / 0.9.8 this week, currently
based off CVS as of 2007-09-13 00:00 GMT.
I have at least a patch pending that I like to
On Sep 11, 2007, at 7:22 AM, Abeni Paolo wrote:
Some times ago I posted a few patches witch added some files. I cut-
and-pasted the copyright statement from other files, but I didn't
put the correct author name into it (I'm not affiliated with
Politecnico di Torino nor with CACE Technologie
On Sep 13, 2007, at 11:14 PM, Pekka Savola wrote:
On Thu, 13 Sep 2007, Guy Harris wrote:
There are differences as to how next-headers are chained in v4 vs
v6. but I'd be tempted to argue that a uniform representation
would be helpful.
Is this inconsistency intentional?
If the inte
701 - 800 of 2513 matches
Mail list logo
