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
On Sep 15, 2007, at 8:01 PM, Jonathan Leffler wrote:
I ended up with a successful compile (under GCC and Sun C) by hacking
config.h, denying that any of the RPC features was present:
What if you instead *don't* hack config.h, leaving it believing you
have getrpcbynumber, but just remove the
On Sep 7, 2007, at 1:23 AM, Abeni Paolo wrote:
following the discussion about the missing direction information in
bluetooth H4 captures(see http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1751)
, I would like to request a new DLT type for a modified bluetooth
linktype.
I'm planning to
On Aug 24, 2007, at 2:33 PM, Luis EG Ontanon wrote:
Hi,
I Need to register two DLTs they would be:
DLT_MTP2_MULTISTANDARD
that will have a one byte pseudo header of which the MS bit indicates
the direction the next three bits are reserved and must be set to zero
in writing the last nibble is u
On Sep 19, 2007, at 12:09 AM, Abeni Paolo wrote:
Thanks! The attached patch used the newly added DLT for hci h4
frames, adding an informative header to each frame.
The header carries (in the first bit in network byte order) the
direction bit for the associated frame and nothing else.
It also
On Sep 19, 2007, at 1:33 AM, Luis EG Ontanon wrote:
On 9/19/07, Guy Harris <[EMAIL PROTECTED]> wrote:
Is a capture likely to have a mix of packets for different MTP3
standards? And are there likely to be more types in the future?
I got few text dumps containing a mix of china and it
On Sep 19, 2007, at 11:49 PM, Varuna De Silva wrote:
I tried to compile a program which includes pcap-int.h,
Why is the program including an internal libpcap file that's *NOT*
part of the official libpcap/WinPcap interface?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca
On Sep 20, 2007, at 5:37 AM, Paolo Abeni wrote:
Hopefully this time the attachment should be plain text and avoiding
strange MS encoding.
Yup, it worked.
Checked in, along with updates to FILES and INSTALL.txt.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscrib
Varuna De Silva wrote:
> 1. what is really meant by the callback routine, what does it do? How
> should I write this function?where should this be written. please be kind
> to guide me to starting place. my idea is that it is the higher layer sw
> which makes use of libpcap.
Yes, the callback fun
On Sep 23, 2007, at 9:08 PM, Varuna De Silva wrote:
On 9/23/07, Guy Harris <[EMAIL PROTECTED]> wrote:
If you're modifying libpcap to support a new type of capture, you
don't
write the callback function,
I am doing this for my device to be supported by wireshark. As I
un
On Sep 24, 2007, at 11:25 AM, Eygene Ryabinkin wrote:
OpenBSD 4.1 introduced an incompatible change to their pflog device
packet header:
...and didn't introduce a new DLT_ value.
It appears that FreeBSD will be doing the same for 7.0, so we just
gave up and said "no pflog dissection except
On Sep 22, 2007, at 12:37 AM, Varuna De Silva wrote:
This is the program pcap-xxx.c which includes in it xxx_open_live()
in it.
That's not a "program" in the sense of an executable program; it's
something you're adding to libpcap, so it's allowed to include pcap-
int.h.
I've checked in
On Sep 24, 2007, at 1:15 AM, Paolo Abeni wrote:
The attached patch is my first attempt to add support to tcpdump for a
'new' DLT (exists in libpcap head, but is currently unknown to
tcpdump).
It print some basic information (hci frame direction) regarding
bluetooth capture.
Checked into the m
On Sep 25, 2007, at 4:33 AM, Varuna De Silva wrote:
1. How should I work around so that pcap_findalldevs() will add my
device in
the list?
If you're doing this on Windows, you will have to:
modify pcap_findalldevs() in fad-win32.c to, right before it does
if (ret =
Varuna De Silva wrote:
> Next I removed the following part from the above code, and the build
> succeeded.
> if (pcap_add_if(alldevsp, "any", 0, any_descr, errbuf) < 0)
> return (-1);
>
> Is this process acceptable of me removing the above part?
Yes. That code is specific to Linux, which
On Sep 25, 2007, at 6:19 AM, Varuna De Silva wrote:
Hello,
I am trying to add support for my device in libpcap(/winpcap) and I
have
some
doubts regarding the xxx_read() function in the pcap-xxx.c file. This
function is there
for the packets to be read in, as I understand. For a previous rep
Varuna De Silva wrote:
> And when we use this FT_Read(), we wait and read in 3968 bytes at a time
So, presumably, if the device has more than 3968 bytes available, only the
first 3968 bytes are read?
What if it has fewer than 3968 bytes available? Does the read return only
what's available?
If
On Oct 1, 2007, at 2:13 AM, Varuna De Silva wrote:
What if it has fewer than 3968 bytes available? Does the read
return only what's available?
It waits checking until it receives 3968 bytes and then read it in
Will it wait forever? If so, that might be a problem if fewer than
3968 byte
On Oct 4, 2007, at 1:58 PM, Stephen Donnelly wrote:
Unmatched parenthesis.
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Oct 4, 2007, at 3:06 PM, Stephen Donnelly wrote:
The attached patch includes:
* Improved error checking in dag_read().
* More efficient dag_platform_finddevs().
* Support for new DAG API function dag_get_stream_erf_types().
* Fix to pcap/pcap.h mismatched parenthesis.
On Oct 2, 2007, at 5:42 AM, Luis Martin Garcia wrote:
I enclose two simple patches to update the "last updated" date of the
manpages.
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Feb 19, 2007, at 12:07 PM, Stephen Donnelly wrote:
It seems that if it is worth making the change, it is also worth
using a
couple of bits to indicate whether a 16 or 32-bit CRC/FCS is present
as
Guy suggested. This could then be used on linktypes such as PPP_SERIAL
which can have either
On Apr 3, 2007, at 2:57 PM, Richard Stearn wrote:
Guy Harris wrote:
pcap-linux.c could map ARPHRD_AX25 to DLT_AX25_KISS, which means AX.
25 captures done on Linux will have a file type of DLT_AX25_KISS.
As in:
declare DLT_AX25_KISS as X
and change:
pcap-linux.c
1140 case
On Oct 5, 2007, at 3:35 PM, sagun shakya wrote:
Improvements after adding support to libpcap:
-
* Observe all IP layer network traffic, including loopback, IPMP
group, IP tunnel traffic and IP layer network traffic flowing to and
from a zone.
Th
On Oct 9, 2007, at 9:12 AM, Gerrit Renker wrote:
having submitted three patches last year on this list which were
accepted but
apparently never made it into the repository,
No, Hannes Gredler checked them into the main branch near at the end
of 2006 - and acknowledged at least two of them
On Oct 10, 2007, at 1:20 AM, Gerrit Renker wrote:
So what happens next - I think that the bug fix should go to the
other branches
as well, since the tool prints the wrong values.
The only relevant branch is the x.9 branch (the other branches are
dead; nobody's going to make an 0.7.x relea
On Oct 19, 2007, at 9:15 AM, Fulko Hew wrote:
Attached is patch file for enabling DLT_SITA support in libpcap.
(so that it can be included in the imminent 1.0 release.)
Checked into the main and 1.0 branches.
Was there a namespace collision with a PPC in some SITA header file?
The PPC in
On Oct 18, 2007, at 9:32 PM, Varuna De Silva wrote:
Hello,
We are trying to decode raw LAPD messages tapped from a
E1 line, with wireshark.
So you're getting, for example, one of the E1's timeslots, which has
an ISDN D channel on it? And the packet data starts with the 2
address octets,
Varuna De Silva wrote:
Yes, Exactly. This is the version LAPD running between two, PABX's.
OK, I've assigned the value 203 to DLT_LAPD.
Note that "the packet data starts with the 2 address octets" means that
the packet contains no indication of whether it's a user-to-network or
network-to-u
Fulko Hew wrote:
Rats! I see it used in one spot in tcpdump/print-atm.c
and it seems that atmuni31.h is also included as part of tcpdump.
So I guess it needs to be changed in that CVS too.
Can you take care of that?
I've preceded all the #defines of VCI values in atmuni31.h with VCI_,
and u
On Oct 24, 2007, at 8:44 AM, Thomas King wrote:
I use libpcap 0.9.7 as provided by openSuSE 10.3. The problem I face
is
exemplified in the source code I attached to this email. The source
code is
an artificially created example to pin-point the problem I have.
Everything
works create unti
Gianluca Varenni wrote:
the attached patch fixes some of the problems in the current wlan code
generation of pcap_compile.
In particular it should fix these problems:
1. the 802.11 header size of a data frame has not a fixed size. When the
QoS bit is set in the subtype field (QoS DATA frame),
On Oct 30, 2007, at 3:42 AM, Guy Harris wrote:
I won't be able to fix that tonight, but, if we delay the release a
couple of days, I might be able to fix that.
Actually, a combination of a brain spasm (see the time above - that
was local time...), a possible watch misconfigur
Guy Harris wrote:
On Oct 30, 2007, at 3:42 AM, Guy Harris wrote:
I won't be able to fix that tonight, but, if we delay the release a
couple of days, I might be able to fix that.
Actually, a combination of a brain spasm (see the time above - that was
local time...), a possible
On Nov 5, 2007, at 2:49 PM, Gianluca Varenni wrote:
I plan to compare this with the old version with the three possible
link layers (bare 802.11, radiotap, PPI)
Actually, there are also 802.11+Prism radio header and 802.11+AVS
radio header; I have some captures with, I think, all of those
Gianluca Varenni wrote:
I think I found the problem:
Yup, I just discovered that myself.
I've checked in a change that fixes it to do
(000) ldb [3]
(001) lsh #8
(002) tax
(003) ldb [2]
(004) or x
(005) st M[0]
(006) tax
(007) txa
(008) add #24
(009) st M
701 - 800 of 2521 matches
Mail list logo
