Re: [tcpdump-workers] DLT_LOOP defined wrong on OpenBSD
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.
Re: [tcpdump-workers] DLT-Value request for IEEE 802.15.4 lrwpan
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 headers, exactly as described in the 802.15.4 spec, yes, you should request a new DLT_IEEE802_15_4 value. The second problem is that I have only access to hardware from the company that I work for (802.15.4 radiochip + MCU on a PCB connected to PC using RS232). The interface is unique to our devices (although it is completely open as all of our SW is GPL). The way I understand how the libpcap works is that this unique interface won't be a problem if I follow the instructions e.g. in http://www.wireshark.org/docs/wsdg_html/#ChapterCapture>. Does this sound reasonable? Yes. As that chapter indicates, see how, for example, it's done in pcap-linux.c for DAG cards. You'd modify the pcap-XXX.c files that would be used on the operating system or operating systems on which your software runs. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Sending captured packets to a virtual nic
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 original article, you said:
I had captured a lot packets from my box, which is a gateway
of a LAN. Those packets are sent back to me. Now I have those packets, I would
like to use the Ethereal for analyzing them.
which seemed to imply that you had a capture file with packets that
you'd already captured. if so, it's too late to do anything in real
time - the capture is already done.
If, instead, you mean that you want, in the future, to be able to
capture packets, and watch them arrive in real time (i.e., view them at
the time that they arrive), then:
So, shortly, I
have captured packets, they come in real-time, but I don't know how to
"replay" those packets to Ethereal.
...transmitting them on a virtual NIC isn't the answer.
As you sent this to tcpdump-workers rather than winpcap-users, I assume
you're doing at least some of this on UN*X.
Therefore, you might be able to, from the box running Wireshark (which
used to be called "Ethereal" in earlier releases; see
http://www.wireshark.org/faq.html#q1.2
if you're curious about the story behind the name change), run tcpdump
on your box over ssh, and send its output to the machine running Wireshark.
What you'd want to do is to, on the machine running Wireshark:
create a named pipe (e.g., with the "mkfifo" or "mknod" command);
use ssh to run tcpdump, in that fashion, on your box - run it with "-s
0" ("-s 65535" with really ancient versions of tcpdump - or, if you
don't want the full packets, pass the appropriate snapshot length) and
"-w -" (so the packets are written to the standard output), and redirect
the output of ssh to the named pipe;
start up Wireshark, and start a capture, capturing from a "device"
whose name is the pathname of the named pipe.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Sending captured packets to a virtual nic
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 what sense? If you mean that you captured a bunch of packets with tcpdump and saved them to a file, and then FTP'ed or scp'd or ... that file to the remote server, that is *not* a real-time transfer - it's not real-time unless each packet is transferred as it arrives. Now the question is how I can open those packets into Wireshark in real-time mode if I just open a file, There is no notion of reading a capture file in real-time mode; that notion wouldn't make any sense. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] another OS X bug: pcap_findalldevs()
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 have it happen. Known problem. If the application using pcap_findalldevs() is built with libpcap from the top of the libpcap_0_9 branch, the problem goes away. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Wireshark-users] Filtering both vlan-tagged
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
capture syntax might be different.
It's always bothered me that it's part of a man page for an application
that's just one of the apps that support libpcap-style filters.
However, I'm not sure the libpcap man page is the right place, either,
as it'll be lost amidst a bunch of details of interest only to people
writing code that uses libpcap.
Wireshark has a "wireshark-filter(4)" man page for its display filter;
would it make sense to have something like a "pcap-filter" man page, to
which the tcpdump/WinDump, libpcap/WinPcap, Wireshark, TShark, and any
other application man pages could refer?
Looking at the FreeBSD man page sections (treating FreeBSD as an example
of the "Version 7/BSD" style of man page sections), pcap-filter - and
wireshark-filter - arguably belong, in systems using the V7/BSD style,
in section 7 ("miscellaneous information pages", or "Macros and
conventions"), rather than section 4 ("introduction to devices and
device drivers", or "Special files").
Looking at the names that Solaris uses for the sections (treating
Solaris as an example of the "System V" style of man page sections), the
appropriate section would probably be section 5 ("Standards,
Environments, and Macros", or "miscellany"), although section 4 ("file
formats") might not be *too* off-base.
Unfortunately, I don't know of any easy way to determine which
convention applies on the target host - I'll see if I can find configure
scripts that install "administrative" tools, and see if they figure out
whether to install the man page in section 8 (on V7/BSD-style systems)
or section 1M (for SV-style systems).
We can probably just pick a section for now, and worry about getting
into the right section later.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT for Radiotap+WiMAX?
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 easiest, and #2 seems most logical. I prefer #1 - it's easier, *and* it seems more logical to me; the most important thing about a capture would seem to me to be the link-layer type, not the fact that it has radio information. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT for Radiotap+WiMAX?
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.
Re: [tcpdump-workers] Tools for stripping parts of a pcap file?
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: [EMAIL PROTECTED] wrote: Does anybody know of a good tool for stripping parts of the packets in a pcap file? Say I have a pcap file containing GRE encapsulated info, and I want to strip the outer IP + GRE headers and leave the rest, writing out the result to another (valid) pcap file I don't know of any tool that would do that, although it might not be *too* painful to write one to do that particular operation. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap format / standard(s)
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 that? :-) We'd like to use pcap as the format for likely obvious reasons, though as I'm looking into the specifics I run into differences in formats outlined at http://www.tcpdump.org/pcap/pcap.html vs. http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html the latter being an update of the former. Am I correct in assuming that the first describes what is actually in use today/still, and the other was more of an update of where things would head (likely to ultimately be a standard)? No. You would be correct in assuming that what is actually in use today is http://wiki.wireshark.org/Development/LibpcapFileFormat which is the current libpcap format, and that http://www.tcpdump.org/pcap/pcap.html was an earlier version of the proposed next-generation libpcap format, and that http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html is an update of that proposed format - that format's current home is on winpcap.org. Currently, I think the only places where the next-generation format (pcap-NG) is used are in some tools from Cace Technologies: http://www.cacetech.com/ for, I think, some aviation instrumentation purposes. Has any further work been done on format/etc. since then (2004)? The page at http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html gives the latest update as September 2006. I have some further changes (which use some currently-reserved fields) that I need to hand to the people working on the pcap-NG spec. They're not at all major (they use the two Reserved bytes in the Interface Description Block to provide multiple namespaces for link-layer types (e.g., to handle the DLT_RAWAF link-layer type family in NetBSD). I don't know what the current plans are for pcap-NG becoming a standard (either official or semi-official). Perhaps we can word our standard such that it allows using the current pcap format or any later format as agreed by both parties (law enforcement and the entity performing the wiretap). I would suggest that, unless you need the features of pcap-NG, you word the standard to support the current libpcap format or any later format as agreed by both parties. If you need a version of that format published on the tcpdump.org site (to make it more "official", although the core tcpdump/libpcap/WinPcap/Wireshark development groups overlap). If you need the pcap-NG features, note that tcpdump, Wireshark, snort, etc. don't support it - and libpcap doesn't support it. If/when a newer version of pcap would come out, do you anticipate libpcap will support backwards compatibility? If pcap-NG becomes official, I would expect libpcap to be able to read both the existing libpcap format and pcap-NG. Applications written to the existing libpcap API will be able to read pcap-NG files that don't use incompatible features (for example, they won't be able to read files that have multiple interfaces with different link-layer types), but they won't see any of the information in pcap-NG files for which there's no provision in the existing API. There will be a future API that exposes all the capabilities of pcap-NG; applications written to that API will be able to read existing libpcap files. Both of the above documents list major version 1, minor version 0; what is put in pcap files today, also 1 and 0, or will there be a way to tell older files from newer ones? What is put in pcap files to day is version 2.4 of the existing libpcap format. There is a way to tell existing libpcap files from pcap-NG files (existing libpcap files begin with 0xa1 0xb2 0xc3 0xd4 or with 0xd4 0xc3 0xb2 0xa1, depending on the native byte order of the machine that wrote the file; pcap-NG files begin with a Section Header Block, which starts with a block type of 0x0d0a0a0d, a 4-byte block length, and a 4- byte Byte-Order Magic value that's either 0x1a2b3c4d or 0x4d3c2b1a, depending on the native byte order of the machine that wrote the file - you need to look at that *before* you interpret the 4-byte block length). Both file formats include version numbers, which is how you tell older versions of the format from newer versions. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Capturing a "clean" TCP stream
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 the application protocol messages, discarding TCP retransmissions). I am currently parsing the TCP header using sequence/ack fields to detect retransmissions and extract payload. Could one suggest a better approach to this? Perhaps I'm missing something, but I can't think of a better approach, other than "use a library that does that work for you, if it exists" (or steal code from an application that does it). I have the impression that a library of that sort might exist, but I don't remember what it might be. You can't specify a filter that will discard retransmissions, as BPF filters are stateless. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] does tcpdump catch all packets in the air?
Ł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 interface into monitor mode and the Kismet drone is probably putting the interface it's using into monitor mode. If you're not in monitor mode, the adapter will only see packets for the wireless network with which you're associated. There's currently no API in libpcap to turn on monitor mode, and no way in tcpdump to turn on monitor mode. You might be able to do so from the command line; see http://wiki.wireshark.org/CaptureSetup/WLAN for some information on this. *However*, note that many adapters will disassociate from your wireless network if put into monitor mode. This might not be what you want. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump/pcap 1-of-S sampling
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 packet.
Rather than do this in the application, I would like to also push this
feature into the kernel
Which kernel?
(i.e. BPF),
I.e., the {Free,Net,Open,DragonFly}BSD kernel, and the Darwin/Mac OS X
kernel, but not the Linux, Solaris, etc. kernel. (And probably not the
AIX kernel, either, unless you work at IBM or an AIX source licensee.)
This is probably going to end up being a private hack unless you
convince the developers of the BPF-using system you're using to adopt
it.
to reduce the amount of kernel-->user
space copying. Ideally, pcap would push the sampling into the kernel
where available, and fall back to doing its own 1-of-S sampling
otherwise.
Does anyone have a recommendation where to store the sampling factor
S,
esp. with regards to passing into the kernel? It doesn't make sense
to
store it in the bpf_insn, so I am thinking that it would make more
sense
to store info in bpf_program.
The best thing to do is probably to provide your own BPF ioctl to set
that, and either
1) have the new ioctl just set the sampling factor, and use the
existing ioctl, unchanged, to set the filter
or
2) add a new ioctl that sets the filter and the sampling factor.
I would vote for 1) as the least intrusive change.
I suspect that the developers of any of the systems in question are
likely to resist a change to the bpf_program structure, for binary and
source compatibility reasons, so if you want this to be anything other
than a private hack, I would suggest that you add a new ioctl to set
the sampling factor.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] cap_compile() generates strange code with DLT_RAW
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) jeq #0x11jt 5 jf 3
{ code=21 jt=2 jf=0 k=17 }
# (003) ldb [9]
{ code=48 jt=0 jf=0 k=9 }
# (004) jeq #0x11jt 5 jf 6
{ code=21 jt=0 jf=1 k=17 }
# (005) ret #65535
{ code=6 jt=0 jf=0 k=65535 }
# (006) ret #0
{ code=6 jt=0 jf=0 k=0 }
It seems to be wrong.
(000) - seems to be nop, why it here?
Probably because the check for the network layer protocol was, for
DLT_RAW, saying "true" for IPv4 or IPv6 and "false" for everything else,
and the "true" test wasn't getting optimized out.
(001), (002) - check that byte with offset 6 (4 bits from flags filed
and 4 bits from fragment offset) equal 17 (protocol number for udp)
It seems to be wrong
...for IPv4, but not for IPv6 (if the next header is UDP).
Since both "is this IPv4?" and "is this IPv6?" were being answered as
"yes", it was testing both the IPv6 "next header" field and the IPv4
"protocol" field, regardless of whether the packet is IPv4 or IPv6.
I've checked in a change to, for DLT_RAW, check the version field of the
IPv4/IPv6 header; the generated code if INET6 is enabled is now:
(000) ldb [0]
(001) and #0xf0
(002) jeq #0x60jt 3jf 5
(003) ldb [6]
(004) jeq #0x11jt 10 jf 11
(005) ldb [0]
(006) and #0xf0
(007) jeq #0x40jt 8jf 11
(008) ldb [9]
(009) jeq #0x11jt 10 jf 11
(010) ret #65535
(011) ret #0
(maybe the check for IPv6 could be "not IPv4", which might avoid the
need for two tests) and if it's not enabled is now:
(000) ldb [0]
(001) and #0xf0
(002) jeq #0x40jt 3jf 6
(003) ldb [9]
(004) jeq #0x11jt 5jf 6
(005) ret #65535
(006) ret #0
(just because libpcap doesn't have IPv6 support, that doesn't mean that
a DLT_RAW file it's reading won't contain IPv6 packets, so it still checks).
This is checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] cap_compile() generates strange code with DLT_RAW
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. mail = CVS head? main = the branch that has the CVS head (I assume "mail" was a typo). Is this in 0.9.5 release? No, because the 0.9.5 release came out before I checked in that change. Any future 0.9.x release will have it, as I checked it into the x.9 branch. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT-Value request for IEEE 802.15.4 lrwpan
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.
Re: [tcpdump-workers] pcap shared libraries: inconsistencies across Linux machines
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 a *sane* shared library mechanism would work, and, as far as I know, it's how the SVR4/ELF shared library mechanism was intended to work. That's the shared library mechanism after which the shared library mechanisms in Linux and the ELF-based BSDs are modeled, as far as I know. So, if you link with "-lpcap", the executable should be bound to libpcap.so.0, *NOT* libpcap.so.0.8.3 or libpcap.so.0.9.4 or whatever. You *did* link with "-lpcap", not "-lpcap.0.8.3" or something such as that, right? ldd output: [EMAIL PROTECTED] ~]$ ldd program83 linux-gate.so.1 => (0x00422000) libnsl.so.1 => /lib/libnsl.so.1 (0x001f6000) libpcap.so.0.8.3 => /usr/lib/libpcap.so.0.8.3 (0x00195000) libc.so.6 => /lib/libc.so.6 (0x00b47000) /lib/ld-linux.so.2 (0x00178000) It sounds as if program83 is bound to the right versions of libnsl and libc - i.e., it appears to be bound to versions with *ONLY* the major version number, *NOT* versions with the full version number. Are the versions of libpcap on the system the ones that came with the system, or did you build and install your own shared libpcap library in /usr/lib? The so files: [EMAIL PROTECTED] ~]$ ls -l /usr/lib/*pcap* lrwxrwxrwx 1 root root 12 Jun 13 20:27 /usr/lib/libpcap.so -> libpcap.so.0 lrwxrwxrwx 1 root root 14 Jun 13 21:22 /usr/lib/libpcap.so.0 -> libpcap.so.0.9 lrwxrwxrwx 1 root root 16 May 3 19:03 /usr/lib/libpcap.so.0.9 - > libpcap.so.0.9.4 -rwxr-xr-x 1 root root 168544 Jul 13 2006 /usr/lib/libpcap.so.0.9.4 What do "ls -l /usr/lib/libc*" and "/usr/lib/libnsl*" print? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] About promiscuous mode
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
libpcap-based applications), and "libpcap-dev" ("dev" in the sense of
people fixing or extending libpcap), so it's probably as good a list as any.
In a switched LAN you will only see broadcasts and packets destined to the
address(es) that are advertised behind your switch port. The sollution
is:
a) use the "monitor" port on your switch
b) use a hub rather than a switch
c) overflow the forwarding table of your switch to turn it into a hub
See
http://wiki.wireshark.org/CaptureSetup/Ethernet
for more information on capturing on a switched Ethernet.
That page refers to
http://wiki.wireshark.org/SwitchReference
which has pages for various switch vendors with instructions, or
pointers to vendor manuals with instructions, on using monitor
ports/mirrored ports/whatever the vendor calls them.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Small configure diff to use pflog header from
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 that can be done without using the host system's if_pflog.h, they probably won't care. If the DLT_ value for pflog files were changed every time the pflog header was changed, that could be done. Unfortunately, that hasn't happened (at least one OpenBSD change doesn't appear to have been accompanied by a DLT_ value change), so, at least for formats used in the past, that can't be fixed. Given that, unless the various systems supporting pflog interfaces are willing to agree to have, in the future, different DLT_ values for different pflog headers (which would probably mean introducing new DLT_ values for all systems, so we can start afresh), my inclination would be to completely omit support for pflog files on systems that don't have a header. (Unfortunately, we can't handle the case of a pflog file from, for example, OpenBSD 3.4 through 3.7 being read on OpenBSD 3.8 through 4.1 - the header format changed, but the DLT_ value didn't - so the only way to detect that is to see that tcpdump etc. just show junk.) As such, I'd be willing to check the change in - if it were modified to completely remove DLT_PFLOG support if there is no header, as a change to make it handle only headers for the OS and version on which it's built would imply no support if a given OS+version doesn't *have* pflog. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump <= 3.9.6 BGP dissector integer overflow
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 buffer is full. I've checked in a fix that does that. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a new DLT
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/indicate that the data stream contains a number of WAN port specific pieces of information such as: - message direction - hardware signal line states (RTS, CTS, DCD, etc.) - transmit/receive error/status bits. - a protocol type indicator (Frame Relay, LAPB, IPARS, UTS, etc.) So a given capture can have packets in it with multiple different protocol types? This 5 byte header/control-structure will be prefixed to each captured data packet, but will not be considered as part of the 'data packet' that will be decoded as part of Wireshark, etc. So will the format of that header be public, or private? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a new DLT
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 example, a WTAP_ENCAP_FRELAY_WITH_PHDR encapsulation type. It currently assumes a pseudo-header with less information than your pseudo-header will provide, but that pseudo-header can be generalized in a way to indicate which pieces of information it has. Its WTAP_ENCAP_LAPB already assumes a pseudo-header with direction information; again, that could be extended. That'd be a bit more work, but I can help with that. (Sigh. I wish pcap-NG and the supporting code were done; it already has, in the packet metadata header, along with the time stamp and lengths, a direction indicator and 16 bits of "link-layer-dependent errors" which could be used for the error/status bits and possibly signal line status - it also has 7 reserved bits that might be usable for that.) - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a new DLT
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 Relay (the existing one) LAPB/X.25 (the existing one) IPARS (one of my new ones) UTS (one of my new ones) It might be possible to use DLT_PPI for this: http://www.cacetech.com/documents/PPI_Header_format_1.0.1.pdf although PPI was originally introduced for 802.11 and might not be ideal for your purposes. If it's not, we'll just go with DLT_ACN_WAN. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a new DLT
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 options open for the future in monitoring other things like STREAMs, named pipes, shared memory communications devices, etc.) So your 4-byte (or 5-byte, as per your original mail) header will be sufficient for that? (Once you've picked a header format, you can't change it - you'd need a different DLT_ value for a different header, as the DLT_ value should be sufficient to allow a file to be interpreted.) - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a new DLT
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 you DLT_SITA, with the value 196. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Problem compiling print-bgp.c (IPV6 disable)
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. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Problem with build of tcpdump-current
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_CONFIG_H -I./missing -D_U_="__attribute__((unused))" -I. -I./../libpcap-2007.07.20 -I./missing -o tcpdump addrtoname.o af.o checksum.o cpack.o gmpls.o oui.o gmt2local.o ipproto.o nlpid.o l2vpn.o machdep.o parsenfsfh.o print-802_11.o print-ap1394.o print-ah.o print-arcnet.o print-aodv.o print-arp.o print-ascii.o print-atalk.o print-atm.o print-beep.o print-bfd.o print-bgp.o print-bootp.o print-cdp.o print-cfm.o print-chdlc.o print-cip.o print-cnfp.o print-dccp.o print-decnet.o print-domain.o print-dtp.o print-dvmrp.o print-enc.o print-egp.o print-eap.o print-eigrp.o print-esp.o print-ether.o print-fddi.o print-fr.o print-gre.o print-hsrp.o print-icmp.o print-igmp.o print-igrp.o print-ip.o print-ipcomp.o print-ipfc.o print-ipx.o print-isakmp.o print-isoclns.o print-juniper.o print-krb.o print-l2tp.o print-lane.o print-ldp.o print-llc.o print-lmp.o print-lspping.o print-lwres.o print-mobile.o print-mpcp.o print-mpls.o print-msdp.o print-nfs.o print-ntp.o print-null.o print-olsr.o print-ospf.o print-pflog.o print-pgm.o print-pim.o print-ppp.o print-pppoe.o print-pptp.o print-radius.o print-raw.o print-rip.o print-rsvp.o print-rx.o print-sctp.o print-sip.o print-sl.oprint-sll.o print-slow.o print-snmp.o print-stp.o print-sunatm.o print-sunrpc.oprint-symantec.o print-syslog.o print-tcp.o print-telnet.o print-tftp.o print-timed.o print-token.o print-udld.o print-udp.o print-vjc.o print-vqp.o print-vrrp.o print-vtp.o print-wb.o print-zephyr.o setsignal.o tcpdump.o util.o version.o print-ip6.o print-ip6opts.o print-mobility.o print-ripng.o print-icmp6.o print-frag6.o print-rt6.o print-ospf6.o print-dhcp6.o print-smb.o smbutil.o strlcat.o strlcpy.o datalinks.o dlnames.o pcap_dump_ftell.o bpf_dump.o ./../libpcap-2007.07.20/libpcap.a ./../libpcap-2007.07.20/libpcap.a(pcap.o)(.text+0x270): In function `pcap_list_datalinks': : multiple definition of `pcap_list_datalinks' datalinks.o(.text+0x0): first defined here It appears that the configure script thinks libpcap doesn't have pcap_list_datalinks() and that your libpcap *does* have it (and that this is true of a bunch of other newer libpcap functions as well). Do you have the config.log script from when you ran configure? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] print-bootp.c: enhancement to decode DHCP option
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.
Re: [tcpdump-workers] Pcap filters for saved capture files?
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 address, but obviously if you're opening a file, there's no device and hence no address. To quote the top-of-tree version of the libpcap man page: int pcap_compile(pcap_t *p, struct bpf_program *fp, const char *str, int optimize, bpf_u_int32 netmask); ... "pcap_compile()" is used to compile the string "str" into a filter program. "program" is a pointer to a "bpf_program" struct and is filled in by "pcap_compile()". "optimize" controls whether optimization on the resulting code is performed. "netmask" specifies the IPv4 netmask of the network on which packets are being captured; it is used only when checking for IPv4 broadcast addresses in the filter program. If the netmask of the network on which packets are being captured isn't known to the program, or if packets are being captured on the Linux "any" pseudo-interface that can capture on more than one network, a value of 0 can be supplied; tests for IPv4 broadcast addreses won't be done correctly, but all other tests in the filter program will be OK. A return of -1 indicates an error in which case "pcap_geterr()" may be used to display the error text. I.e., it's a network mask, not a full IP address, and, if you don't know what the network mask was for the interface on which the capture was done, you can just specify 0, which just means that filters that check for IPv4 broadcast addresses won't work. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT assignment request
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 be available in addition to the existing DLT choices. Forthcoming patches for Wireshark will allow it to completely decode this type, including all of the ERF pseudoheader information. I've assigned 197 for DLT_ERF. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT Request
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 header. We call it an RAIF1 header so something like DLT_RAIF1 would be good. I can make more information available, but currently it's only really useful to our customers that have a board. I note that tcpdump, Snort, Wireshark, and ntop are mentioned on your company's website; will patches for any of those be distributed to handle DLT_RAIF1? In addition, we might want to know what information is provided in the header, to guide future work on the pcap-NG file format and on tcpdump, Wireshark, etc.. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Tcpdump web down?
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.
Re: [tcpdump-workers] Request for a DLT code for IPMB packet
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 packet data will be the slave address, followed by the netFn and LUN, followed by the checksum, etc.? Moreover, Can you tell me how to add a new Capture type to libpcap ? Capture type, or DLT_ type? If you mean "capture type", i.e. a new mechanism for capturing traffic (so that you can capture traffic on the I2C bus), you'd have to modify the pcap-*.c file for the OS on which you're doing this (pcap-win32.c for Windows, pcap-linux.c for Linux, pcap-bpf.c for various BSDs including OS X, pcap-dlpi.c for Solaris and some other UN*Xes, etc.). See, for example, pcap-linux.c's "pcap_open_live()" routine. It checks for some special device names - any name with "dag" in it is assumed to be an Endace DAG device, any name with "septel" in it is assumed to be an Intel SS7 device, etc. - and, for each of the special device name types, calls a special open_live routine. If you want to add an I2C/IPMB capture device, you'd add a similar chunk of code to the open_live routine for the OS you're using, and have it call an open_live routine for I2C/IPMB. That routine would check the device name (it might, for example, be "i2c" or "ipmb"), allocate a pcap_t data structure, and fill it in appropriately. Some of the items to fill in are pointers to routines to, for example, read a new packet from the device. See, for example, the Linux Bluetooth and USB capture devices for examples. Unfortunately, there's no "how to add a new type of capture device" documentation - and the interface for that will probably change at some point. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Data link level type code
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 sent only to the list, by default. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap: Memory-loeaks SIGSEGV
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, *this_dev;
replace
if (pcap_findalldevs(alldevsp, errbuf) == 0) {
with
if (pcap_findalldevs(&alldevs, errbuf) == 0) {
replace
this_dev = *alldevsp;
with
this_dev = alldevs;
and replace
pcap_freealldevs(*alldevsp); // free list memory
with
pcap_freealldevs(alldevs); // free list memory
which will fix the bug in your program that causes the leaks.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT Request
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. changes. I've assigned a value of 198 to DLT_RAIF1. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_LAPB value assignment
[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 the Information field if any? Or would it also contain an extra flag to indicate whether the packet is a DTE->DCE or DCE->DTE packet? Would the packets include the CRC at the end? (I'm assuming they would *not* contain the flag octets at the beginning and the end, and that all bit-stuffing would have been removed.) - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a DLT code for IPMB packet
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 packet data will be the slave address, followed by the netFn and LUN, followed by the checksum, etc.? Moreover, Can you tell me how to add a new Capture type to libpcap ? Capture type, or DLT_ type? If you mean "capture type", i.e. a new mechanism for capturing traffic (so that you can capture traffic on the I2C bus), you'd have to modify the pcap-*.c file for the OS on which you're doing this (pcap-win32.c for Windows, pcap-linux.c for Linux, pcap-bpf.c for various BSDs including OS X, pcap-dlpi.c for Solaris and some other UN*Xes, etc.). See, for example, pcap-linux.c's "pcap_open_live()" routine. It checks for some special device names - any name with "dag" in it is assumed to be an Endace DAG device, any name with "septel" in it is assumed to be an Intel SS7 device, etc. - and, for each of the special device name types, calls a special open_live routine. If you want to add an I2C/IPMB capture device, you'd add a similar chunk of code to the open_live routine for the OS you're using, and have it call an open_live routine for I2C/IPMB. That routine would check the device name (it might, for example, be "i2c" or "ipmb"), allocate a pcap_t data structure, and fill it in appropriately. Some of the items to fill in are pointers to routines to, for example, read a new packet from the device. See, for example, the Linux Bluetooth and USB capture devices for examples. Unfortunately, there's no "how to add a new type of capture device" documentation - and the interface for that will probably change at some point. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a DLT code for IPMB packet
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? I need DLT_ type. I already develop the code for the package by using the DLT_USR14 for this packet. Actually, i know that pcap*.c doesn't support I2C. So i have also build a "Capture engine" to catch raw data from I2C, then save it in a file under hexdump format. After that i will use text2pcap to transfrom this file into pcap file format, then it can be open with Wireshark. Actually, it might be easier just to save it in libpcap format, using, for example, the pcap_dump routines in libpcap. You might also be able to put that capture engine into libpcap, so Wireshark, for example, could do the capturing directly. See, for example, the Linux Bluetooth and USB capture devices for examples. Unfortunately, there's no "how to add a new type of capture device" documentation - and the interface for that will probably change at some point. where can i find the example of USB capture devices ? In the "current tar" version of libpcap, see "pcap-usb-linux.c" and "pcap-usb-linux.h". - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a DLT code for IPMB packet
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 top-of-tree version of libpcap, because it's not a stable release, it's just what's currently at the top of the tree. You'd have to compile and install it yourself, and specially build Wireshark to be linked with it. Oh i used to try to create a pcap format too, but it doesnt work, "Doesn't work" in what sense? and i met too many bugs, What sort of bugs? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_LAPB value assignment
[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 transferred from the DCE to the DTE will contain the address A for the single link operation and address C for the multilink operation. Frames containing responses transferred from the DCE to the DTE will contain the address B for the single link operation and address D for the multilink operation. Frames containing commands transferred from the DTE to the DCE shall contain the address B for the single link operation and address D for the multilink operation. Frames containing responses transferred from the DTE to the DCE shall contain the address A for the single link operation and address C for the multilink operation. with the address A being 0x03, B being 0x01, C being 0x0F, and D being 0x07, so, for example, DCE->DTE frames can contain any one of those four addresses, as can DTE->DCE frames. I.e., for frames going in a given direction, the address encodes whether the frame is a request or a response and whether single-link or multilink operation is being used. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a DLT code for IPMB packet ( WTAP_ENCAP_IPMB
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 forget to add an entry for the new WTAP_ENCAP_IPMB value to the encap_table_base[] array. NOTE: WTAP_ENCAP_ values have no relation to the DLT_ values. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a DLT code for IPMB packet ( WTAP_ENCAP_IPMB
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 don't. You modify wiretap/libpcap.c in Wireshark to map a DLT value of 199 to WTAP_ENCAP_IPMB. (Wireshark doesn't use DLT_ values in its libpcap-reading code, so that it can handle DLT_ values that aren't defined in the libpcap header files on the system on which it's being built.) - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] DLT_LAPB value assignment
[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 field
of the struct pcaprec_ss990915_hdr. Knowing interface index I know
origin, DCE or DTE.
No, please, don't use the non-standard versions of libpcap format - and
especially don't override a completely different field. Just put an
extra byte at the beginning of the packet data.
If you *must* use one of the non-standard versions of the libpcap
header, at least
1) don't use one of the "hack" versions with that SMP debugging gunk in
it, use the pcaprec_modified_header version (called
pcap_sf_patched_pkthdr in libpcap);
2) use a field that's *intended* to convey the direction of the packet,
namely the pkt_type field - use 0 for DCE->DTE ("HOST") and 4 for
DTE->DCE ("OUTGOING").
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_send_packet vs. pcap_inject functions
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 tell one is used on linux and came from winpcap API and the other on bsd systems? No. One was originally implemented in WinPcap, for use on *Windows*; the "Win" in "WinPcap" stands for "Windows". One was originally implemented in OpenBSD. *Neither* was originally implemented on Linux. *Both* should work on Linux - and on OpenBSD, and on Windows, and on FreeBSD, and on NetBSD, and on DragonFly BSD, and on Solaris, and on The two APIs both call the same underlying routine to transmit the packet. pcap_inject() returns the return value of the underlying routine; pcap_sendpacket() checks the return value and, if it's -1, returns -1, otherwise returns 0. A programmer can use whichever of them they want, on whichever OS they want, as long as sending packets is supported on that OS. They are both implemented exactly the same way and accomplish same thing and take the same parameters. So I'm a little confused what is the purpose of having 2 calls? The purpose is to have the newer version of libpcap able to support both programs originally written for WinPcap, using pcap_sendpacket() (just in case they check for success by testing the return value against 0, rather than checking for failure by testing the return value against -1) and programs originally written for OpenBSD's libpcap, using pcap_inject() (just in case they actually care, for some unknown reason, how many packets were actually written; in practice, if the write succeeds, it presumably writes all the bytes of the packet). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] supplying patches to libpcap
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; autoheader; automake) We don't use automake, but we do use the others; autoreconf is sufficient to do all the appropriate stuff for you. to rebuild the appropriate files as part of updating CVS? Yes (at least I do, and I think other people checking in changes do so as well; they should). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] supplying patches to libpcap
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.
Re: [tcpdump-workers] libpcap patches for DLT_SITA support
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. It's derived from the *current* version of pcap.3; I don't think we can commit to keeping it up-to-date with respect to the pcap man page, e.g. if we add new APIs, without an automatic way of generating pcap-sita.html from pcap.3. Perhaps there should be a separate document that describes how the ACN version of libpcap differs from the standard one. 3) is it intended that the ACN version of libpcap be able to capture *only* on ACN devices, not on the regular devices on the machine on which it's installed? It sounds as if IOP-type devices have names with a particular format that isn't likely to match the name of a regular Linux networking device, so it should, I think, be possible to support both. 4) Is the expectation that people not working for SITA (such as SITA's customers) will build and install this? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] print-bootp.c: enhancement to decode DHCP option
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 unsubscribe.
Re: [tcpdump-workers] Adding capture engine questions
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 you verified with tcpdump etc, do you get the same behaviour ? He probably doesn't. It turned out to be the result of a botch in Wireshark, causing pcap_findalldevs() to be called once a second or so, which is a Very Bad Idea, given that it not only fetches the complete interface configuration, it tries to open each interface it finds, in order to determine whether you *can* capture on it. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Having hard time creating my capture device
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. What was the exact message? It could be that the process crashed, perhaps in your code. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Welcome to the tcpdump-workers list!
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 I can enable or disable with the configure script", you do that with "./configure -- help", as you do with any other package that uses an autoconfig script. Look at the "Optional Features" and "Optional Packages" section... ...and note, in particular, that there is *NOT* a "--disable-evp" option. The configure script checks whether there's an openssl/evp.h file and, if there is one, configures tcpdump to use it. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap patches for DLT_SITA support
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 changes, as per the suggestions below, also change
FILES in the new patch.
Perhaps there should be a separate document that describes how the ACN
version of libpcap differs from the standard one.
Thats what that document does.
It also duplicates what's in pcap.3; the problem is that changes to
pcap.3 might render the duplicated stuff out of date.
A document that assumes the reader has already read the libpcap man
page, and just explains what's different about the ACN version, might
require less maintenance.
It sounds as if IOP-type devices have names with
a particular format that isn't likely to match the name of a regular
Linux networking device, so it should, I think, be possible to support
both.
You are correct, I intentionally tried to ensure that my naming
convention was different than that of the other OS I was aware of...
Then, in that case, one version of libpcap could handle both.
So the usual time/budget constraints made me separate the two
functionalities as much as possible. And... I didn't want to 'polute' the
pcap-linux.c file any more than I had to, so I would not confuse people
that followed me in non-ACN-land with un-related code.
pcap-linux.c already has extra stuff to check for a variety of optional
device types; pcap_open_live() would just have
if (the device looks like an ACN device) {
return acn_open_live(device, snaplen, promisc, to_ms, ebuf);
}
added to it, along with all the other checks.
At some point I'll probably look at making it easier to add hooks for
other device types without modifying pcap_open_live().
That would allow users to build libpcap with ACN support, and (with the
top-of-tree version, to which the ACN support would be added) install it
as a shared library, which would mean that applications that can handle
DLT_SITA would handle your devices *without having to be recompiled*.
If you don't have time to add a check like that, just indicate what
names it should check for, and I can add that support.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Welcome to the tcpdump-workers list!
[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 differently for OpenSSL, so that it checks whether the build environment, rather than the host environment, has it. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Reading Memory as a Device
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 memory. Now we want to read this raw data and convert it to pcap format after removing the frame delimiters. How should we start about modifying libpcap if we are to read the memory from where data has been stored. Can we read data as an when it is stored in the buffer by this driver which the manufacturer supplies. I have no idea, as I know nothing about how the driver works or transfers data to memory. That's something you'll have to figure out; all I can help you with is how to plug in *your* code for reading packet data into libpcap. The Tutorial by Carston and Harris deals with network interface cards If you mean "the tutorial by Carstens and Harris": http://www.tcpdump.org/pcap.htm it doesn't deal *at all* with out to modify libpcap; it deals with how to *use* libpcap. There is no tutorial for how to modify libpcap. What you would do is: 1) pick a name or set of names for the device or devices, which will be handed to pcap_open_live() to open your SS7 interface rather than a regular network interface; 2) modify the pcap_open_live() routine for the OS on which you're doing this - as you later say "linux Char Device", I assume that'll be pcap_open_live() in pcap-linux.c - so that it checks for name corresponding to one of your devices and, if it matches, call your own open routine; 3) have a separate pcap-???.c file, with a ???_open_live() routine, which will open whatever device needs to be opened in order to read the raw data; 4) have that routine allocate a pcap_t structure, clear it, and fill it in as appropriate, and return it; 5) have some of the "as appropriate" involve setting all the "_op" pointers in the pcap_t structure: read_op should point to a routine that takes, as an argument, a pointer to a pcap_t, a count, a pointer to a callback routine, and a "u_char *" pointer, and that waits a buffer full of packets to arrive and, when it arrives, calls the callback routine for each packet, passing it, as arguments, the "u_char *", a pointer to a header giving the arrival time of the packet, the packet's length, and the amount of packet data captured; inject_op should point to a routine that fills in the "errbuf" member of the pcap_t with a error message and returns -1, unless you plan to support *sending* packets (which I suspect you don't); setfilter_op should point to a routine that makes a private copy of the filter program passed to it, so that it can later be used by the read_op routine to check whether to call the callback routine with the packet or just discard the packet; setdirection_op can be set to NULL; set_datalink_op can be set to NULL; set_nonblock_op should be set to a routine that arranges that the read_op routine not block waiting for a buffer full of packets to arrive, but just return 0 if a buffer full of packets isn't immediately available (or, if just setting a file descriptor on a device is sufficient, use pcap_setnonblock_fd as the routine); get_nonblock_op should be set to a routine that returns an indication of whether "non-blocking mode", as described in the previous paragraph, is in effect or not (if you used pcap_setnonblock_fd, you can just use pcap_getnonblock_fd); stats_op should be set to a routine that returns some counts of packets received and dropped; close_op should be set to a routine that does whatever is necessary to close the device. Also, set "selectable_fd" to some file descriptor on which you can do a select() to wait for a buffer full of packets to arrive, set "snapshot" to the snapshot length passed in as an argument, and set "linktype" to DLT_MTP2. Can we treat this set of data stored as a linux Char Device and read it with a simple char device driver? Possibly. How does your device driver work? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] RPC responde code question (print-nfs.c)
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 error,
It seems to be one, but it isn't necessarily one.
The code to print that printed "reply OK {length}" if the field in the
packet that, *IF* it contains the beginning of an ONC RPC reply, would
be the reply code is 0, and "reply ERR {length}" if it's not zero.
However, not all packets from an ONC RPC server (such as an NFS server)
necessarily contain the beginning of an ONC RPC reply, as a reply (or
request) can require more than one link-layer packet - for example, an
NFS READ reply that returns more bytes that fit in one Ethernet packet
will, when sent over Ethernet, take more than one Ethernet packet.
If the request or reply is coming over UDP, that's handled by IP
fragmentation; the first packet of the reply will be the first fragment,
i.e. it will have a fragment offset of 0, and can be identified by
looking at the IP header. tcpdump only attempts to dissect the first
fragment as anything other than IP (for one thing, subsequent fragments
don't have UDP or TCP port numbers, so, unless it keeps track of the
fragments, it has no idea what port number any fragment other than the
first one was sent from or to), so it won't try to dissect the
subsequent fragments as if they contained the beginning of an ONC RPC
request or reply.
If, however, it's coming over TCP, that's handled by the RPC
implementation, as TCP merely provides a byte stream, and has no idea
what the message boundaries are for the protocols that run atop it.
Therefore, the current tcpdump code to dissect RPC requests and replies
doesn't identify TCP segments that are in the middle of an ONC RPC
request or reply, and tries to dissect them as if they were at the
beginning of the request or reply.
This can cause packets to be mis-dissected; the apparent RPC errors
you're seeing are probably examples of that.
That part of the code
has changed in tcpdump-3.9.7, which we installed, and now gives :
16:01:19.890794 IP nfs_server.nfs > client_46.1205729087: reply Unknown rpc
response code=3128327487 1448
16:01:19.890831 IP nfs_server.nfs > client_46.3664003007: reply Unknown rpc
response code=910276799 1448
It now prints the value of the field that, if the packet really *is* an
RPC error, would be the error code (the code is derived from from
NetBSD's version of tcpdump). If the packet *isn't* an RPC error, the
value at the location that's interpreted as a reply code has a very good
chance of being bogus, as was the case here.
I don't understand what's happening here. Is it something wrong with our NFS
setup,
No.
or I'm misunderstanding the tcpdump output ?
Yes.
Wireshark/TShark should do a better job of this, for two reasons:
1) it does reassembly of ONC RPC requests and replies over TCP, as well
as handling TCP segments with multiple requests or replies;
2) it does some heuristics to check whether a packet *is* an ONC RPC
request or reply.
1) would probably be a major undertaking to do in tcpdump, but 2) could
be done:
for requests, check whether the RPC version field (not the NFS version)
has the value 2 (neither Sun nor anybody else have released any version
of ONC RPC other than 2), and check whether the program number in the
request is the program number for NFS (note that Sun also run another
RPC protocol on port 2049 - a protocol to allow access to POSIX ACLs
over NFS - which will be misdissected if interpreted as NFS);
for replies, check whether the transaction ID of the reply matches the
transaction ID of a request we've already seen (tcpdump already does
that matching for replies without errors, as it needs to know what type
of request the reply is for).
I'll see whether that could be done.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] ETHERMTU
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 message *when gencode.c is compiled*? If not, then there isn't a problem with gencode.c. if gencode.c (or any other code) is indeed intended for use across several operating systems then it should be careful not pollute name space of the platforms it intends to be used on. gencode.c isn't polluting the name space. Source files don't pollute the name space - header files, such as ethernet.h, do. It's impossible to avoid using names that *might* be defined by *some* header file on a system - even if you manage to avoid every name defined by the header files in one release of a system, the next release might add a new symbol. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] ETHERMTU
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: warning: "ETHERMTU" redefined In file included from /usr/include/netinet/if_ether.h:61, from /usr/include/netinet/ether.h:26, from /pathtocustompackage/customheader.h from ./pcap-int.h:55, from ./gencode.c:65: OK, so you have a *modified* version of gencode.c; this problem doesn't show up with *standard* libpcap. My apologies for loose terminology. I understand it is impossible to predict what symbols might prop up. But to my surprise something like ETHERMTU has been defined in that way and *I wish to only know the reason behind this* The reason behind this is that it's a perfectly reasonable name for the MTU of an Ethernet, that MTU being 1500 bytes (1500 bytes of Ethernet payload, after the 14-byte Ethernet header). If a package supports a OS such as Linux, is it not clean way of being cautious of symbols that OS uses ? No, there is no clean way to be cautious of symbols the OS uses, except not to use any symbols at all, which is a bit impractical. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Small configure diff to use pflog header from
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/INSTALL.txt updated, your name added to the CREDITS files, and with some fixes to libpcap to make it compile on platforms that don't have net/pfvar.h. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump 3.9.8 / libpcap 0.9.8 releases
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).
> - print-icmp.c
>
> -
> struct icmp_mpls_ext_common_header_t {
> };
> -
> This 0-length structure doesn't seem to be used at all and VC6 doesn't
> like
> 0-length structures. Ok to completely remove the structure definition?
Yes - I removed the version you commented out, and propagated that to the
main branch.
> -print-pflog.c: this file does not compile at all because HAVE_NET_PFVAR_H
> is not available under windows. I can probably easily fix it by taking the
> needed files from BSD, but it make take a couple hours to do that.
The only platforms on which print-pflog.c should be compiled are the ones
that have the PF packet filter; Windows isn't one of them, so that
shouldn't be compiled at all on Windows.
> Can we delay the release of 0.9.8/3.9.8 until tomorrow?
Yes - I'd like to at least try to get some of the other stuff people have
asked about checked in as well.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Fix last byte cutoff in printing sctp data byte with -vv
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- data byte. Checked into the main and x.9 branches. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IP length vs IP6 length inconsistency (fwd)
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 specifications, the "total length" in the IPv4 header includes the IP header length, but in v6 the "payload length" doesn't include the initial IPv6 40-byte header length. 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 intent is to display the raw value of the length fields in the headers, then, yes, it is, as the meanings of the length fields differ. Is the length intended to print out the whole IP packet length (which in the case of v6 would probably require chasing down the extension header chain) No, just adding 40 to the payload length field. Extension headers are, according to RFC 2460, included in the length count. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump 3.9.8 / libpcap 0.9.8 releases coming
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 see in. Is there any
chance to get
the patch I posted on 2007-09-11 ('wrong copyright on some files')
merged ?!?
I'll merge it for the final release.
I've checked it in. As noted, it won't be in 0.9.8, because the
Bluetooth and USB support files being patched aren't in 0.9.8.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] wrong copyright on some files
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 Technologies). The attached patch fix the copyright statement in the relevant files. Sorry for the long standing inconsistency. Checked in. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] IP length vs IP6 length inconsistency (fwd)
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 intent is to display the raw value of the length fields in the headers, then, yes, it is, as the meanings of the length fields differ. Well, I guess someone needs to decide what the intent is :-). That's why I phrased it that way. :-) I.e., I can see both sides of the argument, and either choice would work for me. Anybody else want to weigh in? If the intent is to print the raw contents, it'd be helpful if the names of the fields printed were different. Yup - it should distinguish between "total length" and "payload length". Another related problem: tcpdump expressions such as 'less 100' cause similar inconsistency confusion. It seems the length there includes the L2 headers as well, even though the man page speaks of 'packet length' (instead of say, frame length). I wonder if this also is intentional? Probably - there's a BPF instruction to get the raw length of the packet. However, "raw length of the packet" means "amount of data handed to bpf_filter()", which means that it includes the length of any "pseudo- header" prepended to the packet, such as the Prism or AVS or radiotap header for 802.11 packets, or the pseudo-header supplied by SunATM, or The man page should be changed to reflect that. E.g.: I have router advertisements whose IP length (header+payload) is 104 bytes (with -e, ethernet length is 118 bytes). The first value I can see them is with 'less 118' (instead of 'less 104'). So there seems to be an offset of about 14 bytes here. ...at least on Ethernet. Second example are ARP requests/replies whose L2 length is 60 bytes. They can be seen with 'less 60' but no longer with 'less 59'. ...and "60 bytes" includes the padding. Oh, and it's probably *64* bytes if the network adapter and driver supply the CRC (as is the case, for example, on the machine and OS on which I'm typing this). I.e., if you want to filter packets based on the IPv4 length, you should just fetch the length from the IPv4 header using ip[2:2] (and do the equivalent for IPv6); doing that by looking at the link-layer length is a nuisance at best, and a royal pain at worst. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Problem (with outline solution) compiling print-sunrpc.c from tcpdump 3.9.7 (libpcap 0.9.7) on Solaris 10
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 #include line? The Solaris 10 man page for getrpcbynumber(): http://docs.sun.com/app/docs/doc/816-5170/getrpcbynumber-3nsl?a=view just has "#include ". - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] new DLT request
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 add 32 bit header (so big just for alignment purpose) which shall contain the direction information in the first bit. Is there any other requirement/information I have to consider ?!? I've assigned DLT_BLUETOOTH_HCI_H4_WITH_PHDR, with a value of 201. If there's anything else that would be useful, that could be added to the header as well. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] I Need to register some DLTs
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 used to indicate the standard used for mtp3 packets transported (=itu, 0001=ansi, 0010=japan, 0011=china, other values are reserved for future extensions), readers must ignore the contents of the three reserved bits. DLT_MTP3_MULTISTANDARD that will have a one byte pseudo header of which the MS nibble is reserved and must be set to zero in writing the last two are used to indicate the standard used for mtp3 packets transported (=itu, 0001=ansi, 0010=japan, 0011=china, other values are reserved for future extensions), readers must ignore the contents of the reserved bits. 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? If not, should we just have multiple DLT_MTP2_ and DLT_MTP3_ values? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] new DLT request
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 add another pcap header file with the (very basic) definition of the used header Any comments and/or suggestions are very welcome :-) Could you re-attach that patch as text? It appears to be in Microsoft's TNEF format; my machine at work doesn't have software that understands that, and, although my main home machine does, it's currently not working (broken disk drive) - my backup home machine doesn't have de-TNEFifying software on it (although I could dig it up). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] I Need to register some DLTs
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 itu MTP3 headers, other than that I've seen international exchange traces using more than one standard If not, should we just have multiple DLT_MTP2_ and DLT_MTP3_ values? That might be the way. ...although, if a trace can have a mix of packets with different standards, presumably we'd need the DLT_MTP2_MULTISTANDARD and DLT_MTP3_MULTISTANDARD values, rather than just having different DLT_ values for different standards. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Compilation Error - C2894: templates cannot be declared to have 'C' linkage
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/ to unsubscribe.
Re: [tcpdump-workers] new DLT request
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 unsubscribe.
Re: [tcpdump-workers] What is meant by the callback function
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 function is in the higher-layer software that uses libpcap/WinPcap. tcpdump, for example, has two callback functions that write raw packet data to a capture file and one callback function that dissects the packet and prints the dissection; other programs such as Wireshark/TShark, snort, etc. have their own callback functions. The callback function processes the packet data handed to it as the third argument, and the packet time stamp and length information in the structure passed to it as the second argument. If you're modifying libpcap to support a new type of capture, you don't write the callback function, you write code in the read_op routine to call the callback function; a pointer to the callback function is passed to the read_op routine. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] What is meant by the callback function
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
understand
I dont need to write the callback function???
You don't need to write the callback function. Wireshark already has
a callback function, capture_pcap_cb(), in it.
you write code in the read_op routine to call the callback function;
Yes, I did so as following, ( I am guilty, of copying it directly from
pcap-septel.c)
int muwis_read(pcap_t *p, int cnt, pcap_handler callback, u_char
*user)
{
callback(user, &pcap_header, dp);
:
:
}
As I understand this need to be called for each packet captured.
Yes.
a pointer to the callback function is passed to the read_op routine.
This is the "user" in the above code.
No. That's the "callback" in the above code.
"user" is a "u_char *" that's passed to your routine, and that you
pass directly through to the callback; you don't need to do anything
with it - and, as you don't know what it is (it's something that the
callback routine uses), you *shouldn't* do anything with it other than
pass it to the callback routine.
Now my question is what will
be this "user" function in my case. That is when I call _read()
pointer to what function will I have to pass to it as " *user "
You don't call _read() - libpcap does that, in pcap_dispatch(),
pcap_loop(), pcap_next(), and pcap_next_ex().
Your read routine will just take the "user" argument passed to it, and
pass it to the callback function.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [patch] Teach tcpdump to recognize new OpenBSD pflog packets
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 systems that support pflog, and we only dissect pflog files in the format on that machine - get the definition of pflog packets from the system header file". Max Laier submitted a patch to do that, which is checked into the main and x.9 branches. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Compilation Error - C2894: templates cannot be declared to have 'C' linkage
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 a change to the main branch of libpcap to move the
include of outside the extern "C" { } in pcap-int.h, as
pcap.h has its own extern "C" { }. That will probably show up in some
future WinPcap release (as well as a future libpcap release).
You can do the same for your own development.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] add support for bluetooth DLT to tcpdump
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 main branch. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] How to set my device name with pcap_platform_finddevs()
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 == -1) {
/*
* We had an error; free the list we've been
constructing.
*/
if (devlist != NULL) {
pcap_freealldevs(devlist);
devlist = NULL;
}
}
do
if (ret != -1) {
/*
* We haven't had any errors yet; do any
platform-specific
* operations to add devices.
*/
if (pcap_platform_finddevs(&devlist, errbuf) < 0)
ret = -1;
}
Then add a routine to your pcap-xxx.c that, similarly to
septel_platform_finddevs(), adds your device to the list of devices,
and then add a routine to pcap-win32.c called
"pcap_platform_finddevs()" that calls your routine, similarly to the
Linux pcap_platform_finddevs() in pcap-linux.c.
If you're doing this on some form of UN*X, e.g. Linux, just add the
routine to your pcap-xxx.c and find the appropriate pcap-yyy.c and
modify its pcap_platform_finddevs() to call your routine.
2. What is the relationship between pcap_platform_finddevs() and
pcap_findalldevs() function
in this regard ?
pcap_findalldevs() is the routine that finds "standard" network
adapters (i.e., the ones that the OS's mechanism for enumerating
network adapters finds); pcap_platform_finddevs() is the routine that
finds other adapters for a particular platform.
3. How should I modify "pcap_platform_finddevs()" so that I get my
device
added?
See septel_platform_finddevs() for an example.
do I need to do this?
Yes.
4. Where are these two functions written, (pcap_findalldevs() I
found only
in fad32! Sorry
for this foolish question, But I was not able to figure it out)
They're in libpcap, but not in the current version of WinPcap, because
pcap-win32.c and fad-win32.c didn't have them. I've just checked
changes to pcap-win32.c and fad-win32.c into the main branch of
libpcap to add those routines; hopefully they'll appear in a future
version of WinPcap.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] How to set my device name with
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 has a way in which a single descriptor can be used to capture on all the machine's network interfaces; the "any" device lets you use that from tcpdump/Wireshark/etc.. Windows doesn't have that in NDIS, as far as I know (I think you have to bind to a particular NDIS device), so the WinPcap driver can't provide that. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Questions about pcap_read() function
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 reply I got the following. .. routine that takes, as an argument, apointer to a pcap_t, a count, a pointer to a callback routine, and a"u_char *" pointer, and that waits a buffer full of packets to arrive What is this buffer full of packets, Shouldnot I worry about this? The buffer full of packets is whatever you read from your device. Your device (and its driver) might supply one packet at a time, or might buffer up packets and supply multiple packets in a buffer, with a timeout so it doesn't wait forever for a full buffer. and, when it arrives, calls the callback routine for each packet,passing it, as arguments, the "u_char *", a pointer to a header givingthe arrival time of the packet, the packet's length, and the amount of packet data captured; What is the difference between packets length and and amount of packet data captured? The native capture mechanisms on most OSes supported by libpcap, and the WinPcap driver on Windows, allow a capture device to have a "snapshot length". If a packet longer than the snapshot length is captured, the data supplied to libpcap/WinPcap is cut off at the snapshot length, so, for example, with a snapshot length of 128, a packet 128 bytes or less will be supplied in its entirety, while a packet longer than 128 bytes will have only the first 128 bytes supported. This is for use when, for example, you're only interested in TCP's behavior, so you only need enough of the packet to include the TCP header; specifying a snapshot length sufficient to capture the TCP header means that: less data is copied into any buffers used by the capture mechanism, so less CPU time is used, and the buffers are less likely to overflow if there's a high rate of network traffic; less data is copied from those buffers to userland, so, again, less CPU time is used; less data is written to the capture file, so less disk/memory bandwidth is used, and less disk space is used. If a packet is cut short by the snapshot length, the length of the packet as received by the host is the packet's length, and the amount of that data that's supplied to libpcap is the amount of packet data captured. That's what the "-s" flag in tcpdump, Wireshark, and TShark specifies; it can also be specified in the "capture options" dialog box in Wireshark. I am capturing SS7message frames to be sent to WireShark. does this "packet" mean the SS7 frame in my case ? Yes. If So can I capture part of my packet as is depicted by "amount of packet data captured" You could have your code discard any data beyond the snapshot length. Now I have given a handle to my device after opening in at xxx_open_live(). So I have to use that handle here to read the data from the device at xxx_read() right! please correct me? I assume by "handle to [your] device" you mean an internal handle you use to read from your device, not the pcap_t that xxx_open_live() returns. If so, then you'd need to store that handle in a location you can find given the pcap_t pointer; the right place to put it is probably in the "pcap_md" structure defined in pcap-int.h. You would use that handle in the xxx_read() routine. Next we have to remove the frame delimiters(HDLC), to get raw SS7 messages. So I assume your device fills in a buffer of some sort with the data from which you extract the SS7 messages; that buffer would be the "buffer full of packets". ( We had to do it at software level at least for now) Is that done in your driver, or in your libpcap/WinPcap code? I.e., when you read from the device's driver, do you get a raw sequence of octets, with bit-stuffing and frame delimiters in place, or do you get a sequence of SS7 messages, with bit-stuffing and frame delimiters removed? These data will be stored in an ring buffer ( implemented simply as an array) Next is when we access frame by frame with a pointer. My question is that can all these things go in xxx_read() or only the message by message access is possible here, and filtering part do we have to do it in another thread. What do you mean by "filtering part"? When I think of "filtering" in the libpcap/WinPcap context, I think of the filter specified by a pcap_setfilter() call; that filtering would be done in your xxx_read() routine, discarding any packets that don't match the filter, and not supplying them to the callback. Next when I callback, for each packet ( a frame if the answer to a previous question is yes) as below callback(user, &pcap_header, dp); Should this dp ( pointer to the data) point to the starting point of a frame st
Re: [tcpdump-workers] Questions about pcap_read() function
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 no bytes are available, does FT_Read() just block waiting for data to be available? > In order to Identify the frames within this "Buffer full of packets" , our > device attaches flag "7E" at the beginning of a frame and some other data > including the time stamp at the end of the frame. So the device un-does the bit stuffing, but, in order to preserve frame boundaries, the data it hands to the host is byte-stuffed? >> What do you mean by "filtering part"? When I think of "filtering" in >> the libpcap/WinPcap context, I think of the filter specified by a >> pcap_setfilter() call; that filtering would be done in your xxx_read() >> routine, discarding any packets that don't match the filter, and not >> supplying them to the callback. > > The filtering we mean is > 1. To remove the byte stuffing. (Drop Stuffed 7D and inverting of the > particular bit in the subsequent byte) > 2. To remove the 2 CRC bytes at the end. > 3. To extract the Timestamp > and extract the SS7 frame. > > This is what I hope to do for the data in this buffer full of packets, So what you'd do in the xxx_read() routine would be to call FT_Read(), and then scan through the buffer, do the filtering, and, for each SS7 frame you extract through the buffer, call the callback routine. > * caplen - would be the same as packetlen If there's a snapshot length specified (it'd be in the snapshot field of the pcap_t structure), you might want to make caplen be the minimum of packetlen and the snapshot length; your device will still copy the entire packet to the host, but, at least, the application will save only the bytes it asked for. >> It should point to something that will remain unmodified until the >> next xxx_read() call; it sounds as if that means that it can point >> into the buffer. If you're using DLT_MTP2 as your DLT_ type, it >> should point to the first byte of an MTP2 SS7 message. > > In order to have dp remaining till the next call to xxx_read() > we will allocate, an array of 3968 x 2 bytes, so that we will be sure > the data is safe for two rounds of xxx_read() Packet data isn't guaranteed to remain available if the xxx_read() routine is called (once the callback routine returns, the application cannot assume that the packet data is still available - if it wants to use it after the callback routine returns, or after another call to pcap_next() or pcap_next_ex(), it has to make a copy of it), so that's not necessary. > Now Do we need to extract all the frames, when we read in one chunk of > 3968 > bytes? as I understand in septel_read(,int cnt,) function, it > processes only a number of packets specified by cnt. Yes. If the cnt argument is non-zero, you should call the callback routine no more than cnt times; any frames that are still in your buffer should be left there, and processed by any subsequent xxx_read() call *before* reading another bufferful of frames from the device.. If cnt is zero, keep processing frames and calling the callback routine until you run out of frames in the buffer. >> I assume by "handle to [your] device" you mean an internal handle you >> use to read from your device, not the pcap_t that xxx_open_live() >> returns. >> >> If so, then you'd need to store that handle in a location you can find >> given the pcap_t pointer; the right place to put it is probably in the >> "pcap_md" structure defined in pcap-int.h. You would use that handle >> in the xxx_read() routine. > > I have changed the struct ADAPTER (As I remember in Packet32.h) to include > my > handle. So I can have it through the adapter, in pcap_t. Is this alright? I guess that works, but it's not really necessary - adding it to the pcap_md structure will work, too, and means you don't have to modify any of the packet.dll code (and also means that if there's a driver for your device for some form of UN*X, you might be able to use the same code). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Questions about pcap_read() function
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 bytes arrive initially, and it takes a very long time for the last of the 3968 bytes to arrive; that might mean that some SS7 frames won't be seen until a long time after they arrive - and, if more data *never* arrives, those SS7 frames won't *ever* be seen. You should probably use the timeout argument to xxx_open_live(), and have it either 1) wait no longer than that amount of time after the read is done for 3968 bytes of data to arrive or 2) wait no longer than that amount of time after the first byte of data arrives for 3968 bytes of data to arrive. If cnt is zero, keep processing frames and calling the callback routine until you run out of frames in the buffer. Since I hope to do a FT_Read() in every call to xxx_read() You won't necessarily be able to do that. I have to read all the frames in that buffer (3968 bytes), but I guess, I do not have control over cnt variable. Correct. It belongs to a higher layer sw ! is it? Yes. It belongs to the application that's using libpcap/WinPcap. If so how will that piece of Higher layer SW, know to call my xxx_read() with a cnt value of zero or non-zero? That's up to whoever writes the application. Code in libpcap/WinPcap has to be able to handle both zero and non-zero cnt values. Will this reading a chunk of bytes together with reading one frame at a time for each frame in the chunk, work ? Or is it good for me to have a particular library which does all this filtering part and reading of chunks, (in the form of a dll for the moment) and access it? I don't see any benefit to having that in a library separate from the libpcap/WinPcap library, unless you'd use it outside of libpcap/WinPcap. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Recent checkin breaks build
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.
Re: [tcpdump-workers] [PATCH] dag updates
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. Checked in (except for the last one, which was checked in from a previous patch). As changes are made to configure.in, configure will also need to be regenerated using the preferred autoconf version. Done. Note that autoreconf also regenerates config.h.in, so you don't need to send patches for it. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Manpage "Last updated" updated
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.
Re: [tcpdump-workers] Request for a new DLT for MTP2 with FCS
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 length. I checked in a change, based on Florent Drouin's patch, which splits DLT_ and LINKTYPE_ values into: a 10-bit class field, where a class of 0 is for regular DLT_/ LINKTYPE_ values and a class of 0x224 is for NetBSD "RAWAF" values (I don't know whether they're still using them or not); a 16-bit value within that class, which, for a class of 0, is a regular DLT_/LINKTYPE_ value (note that the linktype field in a pcap- NG file is 16 bits); with the class field at the top (so the old DLT_/LINKTYPE_ values still work), and splits the linktype field in the libpcap file header into: a 4-bit FCS length field at the top; a reserved bit below that; a 1-bit field below that, which, if 1, indicates that the FCS length is present; a 26-bit link type, split as per the other split described above. (note that pcap-NG already has a mechanism to supply FCS length information), adds a pcap_datalink_ext() API to get the extra 6 bits of information from the linktype field, and adds macros to manipulate that field. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patch to add DLT_AX25 handling to libpcap
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 ARPHRD_AX25: 1141 handle->linktype = DLT_AX25; 1142 break; to pcap-linux.c 1140 case ARPHRD_AX25: 1141 handle->linktype = DLT_AX25_KISS; 1142 break; I've checked that in, along with your other changes, modified to use DLT_AX25_KISS. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libdlpi with libpcap
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. This will still also allow you see *non*-IP-layer traffic, right? I.e., you'll see all link-layer packets received by the hardware, even if the networking stack would otherwise discard them? Otherwise, it doesn't fully qualify as an "improvement". * Currently, pcap_findalldevs() which lists all the network devices on the system for packet capturing uses SIOCGLIFCONF to generate the list on Solaris. This limits the lists to network devices that are plumbed IP interfaces. libdlpi has an interface dlpi_walk(), which will walk all the network device, thus will provide a complete list. Including SunATM devices? See, for example, pcap_platform_finddevs() in pcap-dlpi.c. I would like to hear from you for suggestions on how libpcap can be updated to libdlpi. I have a couple of possible approaches to make this addition but they may not necessarily be the best approach: 1) Introduce a new pcap-libdlpi-solaris.c file which will handle all the versions of Solaris with libdlpi. The existing pcap-dlpi.c will continue working for pre-libdlpi versions of Solaris. 2) Continue with the use of ifdef #HAVE_SOLARIS approach in the existing pcap-dlpi.c file to call libdlpi functions for releases that support libdlpi. 3) Instead of using libdlpi, add support to open different directories, i.e /dev/net, /dev/ipnet, and add other Solaris- specific ioctls to the existing pcap-dlpi.c file under #ifdef protection. A quick look at http://in.opensolaris.org/os/community/arc/caselog/2007/282/materials/libdlpi-api_updated-txt/ suggests that libdlpi APIs could replace some of the lower-level routines in pcap-dlpi.c - but not the higher-level stuff that pushes STREAMS modules atop the DLPI device, etc. As such, I'd vote for solution 2. pcap_read_dlpi() would presumably continue to directly call getmsg() on the low-level file descriptor, as it's *NOT* getting DLPI messages, it's getting a chunk of packets as delivered by bufmod. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patch-question
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 in an e-mail reply to the list (I only found two patches, the first of which fixed the DCCP bug and added support for variable-length checksums). Were you subscribed to the list at the time? Replies go just to the list, by default. They weren't checked into any of the other branches. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patch-question
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 release), and, as Ken Bantoft indicated in recent mail that he'd "like to see [a 1.0 release of libpcap] out for Halloween, or a week sooner, if that works for everyone", there might not be another x.9 release, either. What will happen to the other two The other two what? Patches? As per my mail: 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 in an e-mail reply to the list (I only found two patches, the first of which fixed the DCCP bug and added support for variable-length checksums). so I'm not sure what patches of yours *haven't* been checked into the main branch by Hannes. Are there any? If so, which ones are they? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap patches for DLT_SITA support
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 atmuni31.h was changed to ATM_PPC. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for DLT value for Raw LAPD
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, followed by the control field, etc.? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for DLT value for Raw LAPD
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-user packet; if you want to include an indication of that sort, your device will have to add that indication to the packet, and the name of the DLT_ value should be changed. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap patches for DLT_SITA support
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 updated print-atm.c for that. (I also changed the libpcap atmuni31.h to prefix all VCI values with VCI_.) - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] After invoking pcap_compile 15 times I get "too many registers needed to evaluate expression"
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 until pcap_compile is invoked the 15th times. As I call pcap_freecode at the end of each loop I would assume that the filter memory should be freed. The registers in question aren't filter-memory resources; the BPF pseudo-machine has 16 scratch memory locations, and if the code generator runs out of scratch memory locations, it fails with that error. What is wrong with my program? Or is this a bug in libpcap? It's a bug in libpcap. I've checked in a fix. (It should only show up if you're capturing from a device that supplies radiotap headers or if you're reading from a capture file with radiotap headers.) BTW, you can (and perhaps should) call pcap_freecode() after calling pcap_setfilter() - pcap_setfilter() makes a copy of the filter if necessary, so the original filter can be freed. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patches for wlan filtering
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), the header is two bytes longer. You can clearly see this on 802.11n APs, that usually use QoS DATA frames. The code does not take into consideration * 802.11n frames containing the HT control field * frames in a WDS (wireless bridges) 2. The optimizer generates buggy code when compiling filters in the form "wlan dst " or similar. The optimizer gets disabled in these cases. 3. Added some code that verifies that a packet is a data frame when accessing the LLC and above protocol fields. I applied the patch (and fixed up the errors from "patch") and changed gen_load_ll_after_802_11_rel() so that, in the "radio header is fixed-length" branch, it sets X to off_ll and loads the Frame Control field from an offset of off_ll - off_ll is equal to the length of the fixed-length radio header, if there is one, and is otherwise 0. With a DLT_IEEE80211 capture, the filter "tcp" generates the code (000) ldb [0] (001) jset #0x4 jt 16 jf 2 (002) ldb [0] (003) jset #0x8 jt 4jf 16 (004) ldx #0x0 (005) ldb [0] (006) jset #0x8 jt 7jf 12 (007) jset #0x4 jt 12 jf 8 (008) jset #0x80jt 9jf 12 (009) ld #0x2 (010) add x (011) tax (012) ldh [x + 30] (013) jeq #0x86dd jt 14 jf 16 (014) ldb [38] (015) jeq #0x6 jt 32 jf 16 (016) ldb [0] (017) jset #0x4 jt 33 jf 18 (018) ldb [0] (019) jset #0x8 jt 20 jf 33 (020) ldx #0x0 (021) ldb [0] (022) jset #0x8 jt 23 jf 28 (023) jset #0x4 jt 28 jf 24 (024) jset #0x80jt 25 jf 28 (025) ld #0x2 (026) add x (027) tax (028) ldh [x + 30] (029) jeq #0x800 jt 30 jf 33 (030) ldb [41] (031) jeq #0x6 jt 32 jf 33 (032) ret #2344 (033) ret #0 Statements 14 and 15 are testing for a protocol of TCP, as are statements 30 and 31, but they're loading from a fixed offset - they need to be loading from an offset modified by the X register. 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. I've attached a patch that applies to the current top of tree, and which includes my changes for fixed-length radio headers. (I also got rid of the #ifdef for the WLAN patches.) Modifications related to 1. and 3. generate code that is not compatible with the optimizer, as gen_load_ll_XXX() generate slist*'s of instructions (where I added the code to verify if a packet is a data/QoS data frame), and not block* chunks. So optimization gets disabled. I'm planning to commit them on the libpcap CVS as disabled patches, and also planning to enable them for the win32 build (winpcap) in the next version that is probably due within some weeks. Any comment/test is more than welcome. Please apply the patch with "patch -p0 gencode.c < wlan_filtering.patch". The patch should work on both HEAD and the libpcap_0_9 branch (I developed it on the libpcap_0_9 branch). Have a nice day GV - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. Index: gencode.c === RCS file: /tcpdump/master/libpcap/gencode.c,v retrieving revision 1.292 diff -c -r1.292 gencode.c *** gencode.c 30 Oct 2007 10:16:45 - 1.292 --- gencode.c 30 Oct 2007 10:40:23 - *** *** 150,156 OR_NET, /* relative to the network-layer header */ OR_NET_NOSNAP, /* relative to the network-layer header, with no SNAP header at the link layer */ OR_TRAN_IPV4, /* relative to the transport-layer header, with IPv4 network layer */ ! OR_TRAN_IPV6/* relative to the transport-layer header, with IPv6 network layer */ }; /* --- 150,157 OR_NET, /* relative to the network-layer header */ OR_NET_NOSNAP, /* relative to the network-layer header, with no SNAP header at the link layer */ OR_TRAN_IPV4, /* relative to the transport-layer header, with IPv4 network layer */ ! OR_TRAN_IPV6, /* relative to the transport-layer header, with IPv6 network layer */ ! OR_LINK_AFTER_WIRELESS_HDR /* After the 802.11 variable length header */ }; /* *** *** 191,196 --- 192,198 static struct block *gen_ncmp(enum e_offrel, bpf_u_int32, bpf_u_int32, bpf_u_int32, bpf_u_int32, int, bpf_int32); static struct slist *gen_load_llrel(u_int, u_int); + static struct slist *gen_load_ll_after_802_11_rel(u_int, u_int);
Re: [tcpdump-workers] Patches for wlan filtering
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 misconfiguration/misbehavior (and lack of a day-of-week indication on said watch), and slightly confusing display in Meeting Maker confused me into thinking today was the 31st. I might be able to fix the code tonight. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patches for wlan filtering
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 watch misconfiguration/misbehavior (and lack of a day-of-week indication on said watch), and slightly confusing display in Meeting Maker confused me into thinking today was the 31st. I might be able to fix the code tonight. Well, it took a bit longer, but I've checked in changes that 1) appear, at least with the regression testing I've done, don't break other link layers (after having fixed some bugs in the code without the changes); 2) appear to do the right thing for various 802.11 link-layer headers - for example, the filter tcp now generates (000) ldx #0x0 (001) txa (002) add #24 (003) st M[0] (004) ldb [x + 0] (005) jset #0x8 jt 6jf 11 (006) jset #0x4 jt 11 jf 7 (007) jset #0x80jt 8jf 11 (008) ld #0x2 (009) add x (010) st M[0] (011) ldb [0] (012) jset #0x4 jt 21 jf 13 (013) ldb [0] (014) jset #0x8 jt 15 jf 21 (015) ldx M[0] (016) ldh [x + 6] (017) jeq #0x86dd jt 18 jf 21 (018) ldx M[0] (019) ldb [x + 14] (020) jeq #0x6 jt 31 jf 21 (021) ldb [0] (022) jset #0x4 jt 32 jf 23 (023) ldb [0] (024) jset #0x8 jt 25 jf 32 (025) ldx M[0] (026) ldh [x + 6] (027) jeq #0x800 jt 28 jf 32 (028) ldx M[0] (029) ldb [x + 17] (030) jeq #0x6 jt 31 jf 32 (031) ret #68 (032) ret #0 for DLT_IEEE802_11. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patches for wlan filtering
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 except for PPI, and will do some tests with those (I looked at the generated code for "tcp" for 802.11 and 802.11+radiotap, and checked the generated code for 802.11+Prism and 802.11+AVS to make sure the code to compute the offsets added in the fixed length of the radio header). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Patches for wlan filtering
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[1] (010) ldb [x + 0] (011) jset #0x8 jt 12 jf 17 (012) jset #0x4 jt 17 jf 13 (013) jset #0x80jt 14 jf 17 (014) ld M[1] (015) add #2 (016) st M[1] (017) ld [4] (018) jeq #0x6900 jt 19 jf 29 (019) ldx M[0] (020) ldb [x + 0] (021) jset #0x4 jt 29 jf 22 (022) ldx M[0] (023) ldb [x + 0] (024) jset #0x8 jt 25 jf 29 (025) ldx M[1] (026) ldh [x + 6] (027) jeq #0x800 jt 28 jf 29 (028) ret #68 (029) ret #0 Try that. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
