[tcpdump-workers] patch to allow tcpslice to work with zero and one packet captures
Do you all maintain tcpslice?
I'm having trouble finding an upstream repo or maintainer for it.
tcpslice fails on packet captures with zero or one packet in them. Given
an arbitrary set of captures, it is entirely possible that some of them
don't have packets or have small numbers of packets.
It is not easy to determine how many packets are in a capture, and
tcpslice itself will write captures with zero or one packets if that is
how many are found in a slice.
This is easily reproduceable with tcpslice by running it with -R to find
the time of the first/last packet in a capture, then creating slices
that have the last packet and no packets.
This patch is against 1.2a3-2.1, and is what I submitted to debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521068
This
http://www.tcpdump.org/related.html
Says
TCPslice can also be found in the tcpdump CVS server, as the project tcpslice.
But cvs is gone, and it doesn't seem to be in git?
Index: search.c
===
--- search.c (revision 401)
+++ search.c (working copy)
@@ -319,8 +327,25 @@
if ( fread( (char *) bufpos, num_bytes, 1, pcap_file( p ) ) != 1 )
goto done;
- if ( find_header( p, bufpos, num_bytes,
- first_time, 0L, &hdrpos, &hdr ) != HEADER_DEFINITELY )
+ status = find_header( p, bufpos, num_bytes,
+ first_time, 0L, &hdrpos, &hdr );
+
+/* When find_header finds what looks like a header it tries to verify
+ * that looking forward by caplen also finds what looks like a header.
+ * If moving forward points past the end of the buffer it returns
+ * _PERHAPS, because there wasn't enough data passed to it to verify
+ * the next header. However, we know that the buffer ends with the
+ * last data in the file. If the _PERHAPS header just found + caplen
+ * points to exactly past the end of the file, that's as-if it pointed
+ * to a valid header, and we promote _PERHAPS to _DEFINITELY.
+ *
+ * This condition occurs with a single-packet capture.
+ */
+if ( status == HEADER_PERHAPS &&
+ ( hdrpos + PACKET_HDR_LEN + hdr.caplen ) == bufend )
+ status = HEADER_DEFINITELY;
+
+ if ( status != HEADER_DEFINITELY )
goto done;
/* Okay, we have a definite header in our hands. Follow its
Index: tcpslice.c
===
--- tcpslice.c (revision 401)
+++ tcpslice.c (working copy)
@@ -114,6 +112,7 @@
struct timeval first_packet_time(char filename[], pcap_t **p_addr);
struct timeval lowest_start_time(struct state *states, int numfiles);
void get_next_packet(struct state *s);
+void get_first_packet(const char *filename, pcap_t *p, struct pcap_pkthdr *hdr);
struct state *open_files(char *filenames[], int numfiles);
void extract_slice(struct state *states, int numfiles, char *write_file_name,
struct timeval *start_time, struct timeval *stop_time,
@@ -476,7 +475,9 @@
{
*first_time = first_packet_time( filename, p );
- if ( ! sf_find_end( *p, first_time, last_time ) )
+ *last_time = *first_time;
+
+ if ( first_time->tv_sec && ! sf_find_end( *p, first_time, last_time ) )
error( "couldn't find final packet in file %s", filename );
}
@@ -496,8 +497,7 @@
if (! p)
error( "bad tcpdump file %s: %s", filename, errbuf );
- if (pcap_next(p, &hdr) == 0)
- error( "bad status reading first packet in %s", filename );
+ get_first_packet(filename, p, &hdr);
return hdr.ts;
}
@@ -530,6 +530,27 @@
}
}
+/* Get the first record in a file. Deal with empty captures. */
+void
+get_first_packet(const char *filename, pcap_t *p, struct pcap_pkthdr *hdr)
+{
+ struct pcap_pkthdr *next_hdr = 0;
+ const u_char *next_data = 0;
+ switch (pcap_next_ex(p, &next_hdr, &next_data))
+ {
+ case 1: /* success */
+ *hdr = *next_hdr;
+ break;
+ case -2: /* no more packets to read from the save-file */
+ /* valid but empty pcap, start and end time will be zero */
+ memset(hdr, 0, sizeof(*hdr));
+ break;
+ default:
+ error( "bad status reading first packet in %s: %s",
+ filename, pcap_geterr( p ) );
+ }
+}
+
struct state *
open_files(char *filenames[], int numfiles)
{
@@ -561,16 +582,20 @@
s->start_pos = FTELL( pcap_file( s->p ) );
- if (pcap_next(s->p, &s->hdr) == 0)
- error( "error reading packet in %s: ",
-s->filename, pcap_geterr( s->p ) );
+ get_first_packet(s->filename, s->p, &s->hdr);
s->file_start_time = s->hdr.ts;
- if ( ! sf_find_end( s->p, &s->file_start_time,
- &s->file_stop_time ) )
- error( "problems finding end packet of file %s",
-s->filename );
+ /* For 0-packet captures the start time is 0, don't search for an
+ * end time.
+ */
+ if ( s->file_start_time.tv_sec )
+ {
+ if ( ! sf_find_end( s->p, &s->file_start_time,
+ &s->file_stop_time ) )
+error( "problems finding end packet of file %s",
+ s->filename );
+ }
s->stop_pos = FTELL( pcap_
Re: [tcpdump-workers] patch to allow tcpslice to work with zero and
On Wed, Mar 25, 2009 at 7:26 PM, Michael Richardson wrote: > > Yes, we do take patches for tcpslice. > > Sam, please send GPG signed SSH key, and we can move the CVS into git... > The CVS isn't gone, it's just not primary. Here you go. Do the patches look ok? They work well for us. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ssh-rsa B3NzaC1yc2EBIwAAAIEAlrpPwWtOCttWUibhtI8N3MY/BnvU4m+nwOJBAFI1rXclclOH5qs5IJ82BRZp45SmSpHUEnmMN1cqWetmrgTQwvWQZk/EUGhPQqP50Jeazljh+pmv+CfAcWmBkFqsSKQZBoG3tOmWvhlJPMGmZnLe8/Kfwef3ljzH+sBH9pFpV0c= s...@ensemble.local. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknRmMsACgkQLoHQlTvkuwvhJQCdEn8yBDYUdSEFb+9JiNcDQQPG XpsAn0nJaP0sq26lNBJcnufOfkx72F5m =1PFa -END PGP SIGNATURE- - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] patch to allow tcpslice to work with zero and one packet captures
On Wed, Mar 25, 2009 at 5:59 PM, Sam Roberts wrote: > tcpslice fails on packet captures with zero or one packet in them. Given > an arbitrary set of captures, it is entirely possible that some of them > don't have packets or have small numbers of packets. Anything else I need to push this patch upstream? We'll need to keep building our .deb packages of it for years, but one day I hope to see these come back to me an an OS update! :-) Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] my problem to install tcpdump
On Wed, Apr 1, 2009 at 10:09 AM, Ahmad Vakili wrote: > Dear Sir/Madam > > I wanted to install tcpdump in my Debian (as a virtual machine on my mac). sudo apt-get install tcpdump - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] request for DLT_WIHART for Wireless HART
Wireless HART is a wireless industrial control protocol that uses the IEEE 802.15.4 physical layer, but_ NOT_ the IEEE data-link layer. The encapsulation consists of the entire data-link PDU (similar to 802_15_4). The spec is available for a fee from http://www.hartcomm2.org. Since it was submitted to the IEC as IEC/PAS 62591, the spec is available for a substantially smaller fee from http://webstore.iec.ch/webstore/webstore.nsf/artnum/042507. I'll post dissectors to wireshark once I've a DLT type. Thanks, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Fwd: Re: Thread Safe Lexer]
On Wed, Jul 1, 2009 at 12:32 PM, Eloy Paris wrote: > Do we use Flex and Bison on all supported platforms, or we have things > setup so we use the original Lex and Yacc on some platforms to have > backward source code compatibility? Sorry if this is noise (it's been a while since I've used flex/bison), but don't they generate portable C code, and isn't it that code that is in the released source tarballs? Actually building tcpdump should not require flex or bison, only hacking on it from an svn checkout should require that, and if the flex/bison output was checked in, even that should be only when modifying the parser. Anybody hacking on the source should be OK with installing/updating the tools they need. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] build a raw packet
On Wed, Dec 15, 2010 at 2:06 PM, Aaron Turner wrote: > Look at libdnet and libnet. I'll state right here and now that libnet > doesn't seem to be properly maintained anymore and I've had issues > compiling against the library headers in the past. I'm maintaining libnet (out of necessity, not labour of love). If you find problems, I'll take bug reports or patches. Thanks, Sam https://github.com/sam-github/libnet http://sourceforge.net/projects/libnet-dev/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] New page, giving link-layer header type values
On Sun, Mar 13, 2011 at 2:41 PM, Guy Harris wrote: > http://www.tcpdump.org/linktypes.html > > contains a description of all the existing link-layer header types for which > there is either Not sure why there is two link types for IEEE 802.15.4. The "no FCS at the end" case doesn't need a link type, if the snaplen is 2 bytes shorter than the packet should be, then there is no FCS at the end. Since every decoder needs to know how to deal with a snaplen less than the original packet length (don't they?), we've been writing pcaps from a usbkey that gives us packet captures without FCS, and I just set the snaplen to what we got, and they decode fine. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] New page, giving link-layer header type values
On Tue, Mar 15, 2011 at 5:11 PM, Guy Harris wrote:
> On Mar 15, 2011, at 4:51 PM, Sam Roberts wrote:
>
>> On Sun, Mar 13, 2011 at 2:41 PM, Guy Harris wrote:
>>> http://www.tcpdump.org/linktypes.html
>>>
>>> contains a description of all the existing link-layer header types for
>>> which there is either
>>
>> Not sure why there is two link types for IEEE 802.15.4.
>
> Because this has to work with pcap as well as with pcap-ng, and pcap, unlike
> pcap-ng, has no way to indicate whether a packet has an FCS.
Sorry, I've never used pcap-ng, so my comments apply solely to pcap.
>> The "no FCS at the end" case doesn't need a link type, if the snaplen
>> is 2 bytes shorter than the packet should be, then there is no FCS at
>> the end.
>
> That's a heuristic; heuristics are what you use when you have to work around
> the lack of information. That particular heuristic assumes that packets are
> as big as they "should be", which isn't necessarily guaranteed.
I don't understand your explanation.
It sounds like you think there are two variants of 802.15.4, one with
an FCS, and one without. As far as I know, thats not the case (but I
don't pretend to have memorized the whole spec, I just implemented
enough to get zbee traffic across it).
Whether or not the radio chips give the FCS to you when you run them
in sniffer mode depends on the chip. Many just validate the FCS, strip
it, and pass you the packet minus the FCS, but some give you the whole
packet, including the FCS. And some don't give you the FCS, they
replace it with a 2 byte indication of signal strength and quality,
which is useful,but unfortunately including that in the pcap would
require a different DLT_ type, because it is no longer a standard
physical layer frame.
Either way, the FCS was there on the data link, we just don't have it.
Since we only got ("snapped") the packet up to the FCS, we write what
we got and set the snaplen.
How is it a heuristic to notice that the entire packet is not present
in the pcap? If you only write 1 byte, is it a "heuristic" to notice
that the complete 15.4 link layer header isn't there, much less the
payload or the FCS?
Cheers,
Sam
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] New page, giving link-layer header type values
On Tue, Mar 15, 2011 at 6:41 PM, Guy Harris wrote: > On Mar 15, 2011, at 5:58 PM, Sam Roberts wrote: >> Whether or not the radio chips give the FCS to you when you run them >> in sniffer mode depends on the chip. Many just validate the FCS, strip >> it, and pass you the packet minus the FCS, but some give you the whole >> packet, including the FCS. And some don't give you the FCS, they >> replace it with a 2 byte indication of signal strength and quality, >> which is useful,but unfortunately including that in the pcap would >> require a different DLT_ type, because it is no longer a standard >> physical layer frame. > > Yes, and it probably *SHOULD* get a different LINKTYPE_/DLT_ value, so that > it can be included in captures and dissected by programs that do captures and > read capture files. (If it could be moved to the beginning of the packet > without doing any copying other than of the 2 bytes in question, that would > probably be best.) It can, but the meaning might be specific to that chipset, I don't know enough about the physical layer to comment. It took us a while to figure out this was what was happening (as an FCS, it didn't compute). >> How is it a heuristic to notice that the entire packet is not present >> in the pcap? > > It's a heuristic to deduce that this is because the FCS wasn't provided by > the capture hardware rather than because the user captured with a "-s" flag. Why would anyone want to deduce this? In wireshark, both dlt values will map to the same dissector, and maybe they will bother putting some kind of 'no FCS' phrase on the link layer section, but who cares when looking at a PCAP about the internal details of the the capture chip? If a company makes an ethernet tap device, and for some reason, made it refuse to return more than the first 60 bytes of ethernet frames even with tcpdump -s80 (maybe its "super performance mode"), would you allocate me a new DLT type, or just say I wrote broken hardware? Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] New page, giving link-layer header type values
On Tue, Mar 15, 2011 at 8:59 PM, Guy Harris wrote: > On Mar 15, 2011, at 8:27 PM, Sam Roberts wrote: > >> Why would anyone want to deduce this? In wireshark, both dlt values >> will map to the same dissector, > > They *shouldn't* map to the same dissector. They should map to *different* > dissector routines, which call a common routine, passing an "FCS present" > flag; if the flag indicates that the FCS is present, they'll look for it and > show it, otherwise they'll just leave the FCS out of the dissection. They will map to the same dissector, thats what I'm trying to say, WITHOUT heuristics. I've got the pdf at work, but from memory, its basically something like: ctrl, 1 byte ... optional fields (present if bit set in control, each control bit maps to presense or absence of an optional header field) length field (not optional) FCS so the dissector just walks the data from the pcap, dissecting until hitting snaplen. If snaplen was 1, it would just read the control. If snaplen is 6, the control and (probably) src/dst address fields. etc. Same code. Stop when there is no more data. If the FCS was the first byte in the packet, then it would be a different format. Or if there was no length field in the header, so you didn't know when the data ended, but thats not the case. 15.4 is not like ethernet, where the header doesn't have any indication of the length, so if you got the FCS at the end, you couldn't tell if it was data or not, and you'd have to dig into the ethernet payload, and figure out how long the IPv4 thought the packet was, and the see that the FCS was at the end. > Note, by the way, that there are actually *three* LINKTYPE_/DLT_ values for > 802.15.4. The third one is > LINKTYPE_IEEE802_15_4_NONASK_PHY/DLT_IEEE802_15_4_NONASK_PHY; the description > is Yes, that is actually a totally different packet format, thats why I didn't mention it. Its a representation of the packet on the air. Its the equivalent of an ethernet frame on the wire which has the 7 octet preamble, start of frame delimiter, and then the DLT_EN10 ethernet header with dstmac, srcmac, etc... > (as outgoing packets won't have the FCS). Unfortunately, I *wasn't* asked, > so we had to crap up the Ethernet dissector in Wireshark with code > to cope > with that as best it can. I *REALLY* do not want to have to do that again, > or even be asked to do that again (that's one of the reasons > why I wanted > pcap-ng to have per-packet attributes to indicate whether the FCS is present > - and, given that in, for example, PPP, the FCS > length can be negotiated, to indicate the length of the FCS.) I totally sympathize, its awful, but this isn't the same. Heuristics not required. As long as the code can deal with truncated packets (which is what the second _NO_FCS DLT is, its a truncated form of the first), the code will be the same. Otherwise, its no big deal to me, it looks a bit odd, like somebody didn't have the FCS, and it didn't occur to them that it was a truncated packet and they could just set the snaplen to the length of data they had, and use the existing DLT. So, they asked you for a DLT value, and you'd rather have too many than repeat some of the mistakes of the past, so you issued one, and there is now a second DLT value. Maybe you can't withdraw a DLT, anyhow, so we're both wasting our time here? Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_findalldevs, pcap_addr doesn't have
On Sat, Apr 2, 2011 at 7:40 PM, Bob wrote: > Also, any suggestions for a cross-platform means of getting a MAC address > (AF_LINK). On BSD i can use socketaddr_dl from if_dl.h, but Linux doesn't > have this. I'm not even sure about windows. libnet has a libnet_get_hwaddr(), might work across your platforms. http://sourceforge.net/projects/libnet-dev/ Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] corrupted frame on kernel ring mac with ubuntu10.10, libpcap 1.1.1, linux 2.6.38
I'm running into the corrupted mmapped ring buffer problem, but only
with my very simple code - not with the packaged tcpdump or wireshark.
I don't have the problem with a local build of libpcap from git.
Does anybody here know what causes this? Am I calling libpcap
incorrectly? Is it a pure ubuntu problem I should report up to them?
Here's the output of tstpcap.sh, which builds and runs tstpcap.c
twice, against the system libpcap and my own build:
% sh tstpcap.sh
+ gcc -Wall -o tstpcap-git tstpcap.c -L/usr/local/lib -lpcap
+ gcc -Wall -o tstpcap-ubuntu tstpcap.c -lpcap
+ ldd tstpcap-git tstpcap-ubuntu
tstpcap-git:
linux-gate.so.1 => (0xb78b9000)
libpcap.so.1 => /usr/local/lib/libpcap.so.1 (0xb7869000)
libc.so.6 => /lib/libc.so.6 (0xb770c000)
/lib/ld-linux.so.2 (0xb78ba000)
tstpcap-ubuntu:
linux-gate.so.1 => (0xb76fb000)
libpcap.so.0.8 => /usr/lib/libpcap.so.0.8 (0xb76ad000)
libc.so.6 => /lib/libc.so.6 (0xb755)
/lib/ld-linux.so.2 (0xb76fc000)
+ uname -a
Linux samtu 2.6.38-020638-generic #201103151303 SMP Tue Mar 15
14:33:40 UTC 2011 i686 GNU/Linux
+ sudo ./tstpcap-ubuntu eth0
version libpcap version 1.1.1
return -1 error? corrupted frame on kernel ring mac offset 70 + caplen
0 > frame len 64
+ sudo ./tstpcap-git eth0
version libpcap version 1.3.0-PRE-GIT_2011_04_18
return 1 error?
% cat tstpcap.sh
set -x
gcc -Wall -o tstpcap-git tstpcap.c -L/usr/local/lib -lpcap
gcc -Wall -o tstpcap-ubuntu tstpcap.c -lpcap
ldd tstpcap-git tstpcap-ubuntu
uname -a
sudo ./tstpcap-ubuntu eth0
sudo ./tstpcap-git eth0
% cat tstpcap.c
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
char* source = argv[1];
int snaplen = 0;
int promisc = 0;
int to_ms = 0;
char errbuf[PCAP_ERRBUF_SIZE];
printf("version %s\n", pcap_lib_version());
pcap_t* cap = pcap_open_live(source, snaplen, promisc, to_ms, errbuf);
if(!cap) {
printf("error %s\n", errbuf);
return 1;
}
struct pcap_pkthdr* pkt_header = NULL;
const u_char* pkt_data = NULL;
int e = pcap_next_ex(cap, &pkt_header, &pkt_data);
printf("return %d error? %s\n", e, pcap_geterr(cap));
return 0;
}
tstpcap.sh
Description: Bourne shell script
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
char* source = argv[1];
int snaplen = 0;
int promisc = 0;
int to_ms = 0;
char errbuf[PCAP_ERRBUF_SIZE];
printf("version %s\n", pcap_lib_version());
pcap_t* cap = pcap_open_live(source, snaplen, promisc, to_ms, errbuf);
if(!cap) {
printf("error %s\n", errbuf);
return 1;
}
struct pcap_pkthdr* pkt_header = NULL;
const u_char* pkt_data = NULL;
int e = pcap_next_ex(cap, &pkt_header, &pkt_data);
printf("return %d error? %s\n", e, pcap_geterr(cap));
return 0;
}
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [libpcap][patch] appending to a capture
On Wed, Jun 1, 2011 at 11:13 AM, Michael Richardson wrote: > Yeah, I'd rather that we have a good set of pcap manipulation tools. > Maybe we just need better pointers to mergecap and editcap? I don't see extensions to libpcap and a good set of tools as an either/or thing. I'd be pretty happy to see the capabilities of tools such as mergecap, editcap, and tcpslice presented as C callable APIs. Its possible to shell out to do pcap manipulations, but its often more useful to bind C APIs into your working language, allowing you to combine effects in interesting ways that might not be forseen by the command line tools. If not in libpcap, maybe libcaptool? Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump and BPF filters
On Tue, Jul 12, 2011 at 1:57 PM, Geoffrey Sisson wrote: > extension to libpcap's filter language, though. My initial query was > whether there's a way to supply tcpdump with a BPF filter expression, > bypassing the libpcap filter language altogether. This is useful for > cases where a filter can be constructed for the BPF that cannot be > expressed as a libpcap filter expression. Since you are contemplating writing BPF filters by hand, you probably already have considered this, but I think you could modify tcpdump to create a bpf_program from your input, bypassing its call to pcap_compile(). Maybe use -F to provide the raw instructions. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a DLT value (for nflog)
On Mon, Jun 20, 2011 at 3:21 AM, Jakub Zawadzki wrote: > DLT_NFLOG starts with struct nfgenmsg header defined in > , > which looks like (changed to stdint.h types + my comments in /** **/): Do you have a way of capturing traffic on a netlink socket? I've wanted one very much, to capture NFQ and NFCT. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] having trouble using libpcap to write DLT_USER0 captures
DLT_USER0 is available for internal use, and pcap_open_dead() will
accept it, but pcap_dump_open() is complaining that it doesn't know
the corresponding link type.
I assume this is intentional, but why is it a feature? It seems
preferable that people use libpcap to write pcap files than rolling
their own, probably buggy, versions.
With the change below I can write USER0 pcaps and read them with wireshark.
Cheers,
Sam
diff --git a/pcap-common.c b/pcap-common.c
index a0eb3a2..bd78dc3 100644
--- a/pcap-common.c
+++ b/pcap-common.c
@@ -1212,6 +1212,10 @@ dlt_to_linktype(int dlt)
return (map[i].linktype);
}
+if (dlt >= DLT_USER0 && dlt <= DLT_USER15) {
+return dlt;
+}
+
/*
* If we don't have a mapping for this DLT_ code, return an
* error; that means that the table above needs to have an
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] having trouble using libpcap to write DLT_USER0 captures
Did this get missed? Is the patch not good?
libpcap can read user0 caps, it should be able to write them.
Cheers,
Sam
On Tue, Nov 29, 2011 at 11:38 AM, Sam Roberts wrote:
> DLT_USER0 is available for internal use, and pcap_open_dead() will
> accept it, but pcap_dump_open() is complaining that it doesn't know
> the corresponding link type.
>
> I assume this is intentional, but why is it a feature? It seems
> preferable that people use libpcap to write pcap files than rolling
> their own, probably buggy, versions.
>
> With the change below I can write USER0 pcaps and read them with wireshark.
>
> Cheers,
> Sam
>
>
> diff --git a/pcap-common.c b/pcap-common.c
> index a0eb3a2..bd78dc3 100644
> --- a/pcap-common.c
> +++ b/pcap-common.c
> @@ -1212,6 +1212,10 @@ dlt_to_linktype(int dlt)
> return (map[i].linktype);
> }
>
> + if (dlt >= DLT_USER0 && dlt <= DLT_USER15) {
> + return dlt;
> + }
> +
>
> /*
> * If we don't have a mapping for this DLT_ code, return an
> * error; that means that the table above needs to have an
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Exception conditions on pcap descriptors?
On Thu, Dec 29, 2011 at 3:45 PM, Fernando Gont wrote: > I'm doing I/O multiplexing by obtaining the underlying file descriptor > for the pcap_t "socket", with pcap_fileno(). > > I was wondering whether I should check for exceptions on such descriptor > (in addition to readability and writeability), and whether such > exceptions could possibly occur (and if so, what the possible causes of > such exceptions could be). Socket exception checked with select aren't exceptions in the sense of error, they are what is more commonly called out-of-band data. Its a perpetual source of confusion. You should only have to check for readability, if there is an error pending on the socket it will be readable, and read/recv will return the error. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Initializing a device
On Wed, Jan 4, 2012 at 4:10 PM, Akos Vandra wrote: > When opening a capture device, is it possible to hand off some > initialization data to the libpcap handler? I'm not a developer of libpcap/tcpdump, but I don't think so. > For example, I have just added a handler for a canusb device. When > opening the device, it would be nice if it was possible to set the > baud rate, etc. Isn't this the kind of thing that would be set up before hand? Kindof like you don't setup an ethernet device with libpcap, you set it up with ifconfig or whatever, and then use it with libpcap. baud rate makes it sound like it should respond to the termios system calls, or be configurable with stty, and a user would make setting permanent use rc scripts, or a udev rule. Or if they need to use some tool specific to your can device, then you'd provide that tool. > Would it be possible to use the BPF filter for this? I doubt it. Filters are a mini assembly language run on packets to see if they should be selected for capture. The tcpdump command line filter expression is compiled into the assembly language. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_t not writeable on OpenBSD
On Mon, Jan 9, 2012 at 8:49 PM, Fernando Gont wrote: > I'm doing I/O multiplexing with the pcap descriptor, and it turns out > that on OpenBSD the underlying descriptor for a pcap_t is never writeable. > Note: No problems in Linux and FreeBSD -- so far only in OpenBSD. Are you capturing, or injecting? Shouldn't you be waiting for it to be readable for capture? For injection, on linux anyhow, a PF_PACKET device is always writeable, but I'm pretty sure it discards packets if you write too fast. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Wireshark-dev] tcpdump-workers mailing list troubles
For what its worth, the last message I saw was on Mar 13th, thought I have 2 or 3 more messages than I can see on http://news.gmane.org/gmane.network.tcpdump.devel I'm CCing tcpdump-workers, I'll see if I have the problem, too. Sam On Wed, Apr 18, 2012 at 1:52 PM, Christopher Maynard wrote: > I have been having trouble with the tcpdump-workers mailing list and since I > know at least some of the folks subscribed to this list are also subscribed to > that one, I thought I might mention the troubles I've seen to see if anyone > else > is also experiencing the same troubles and if anyone here might be in a > position > to help resolve the problems or perhaps advise me of some other course of > action > that I could take. > > 1) I have not seen any activity on the list for over a month, which seems odd > to > me right there, although not conclusive of a problem in itself, except that > ... > > 2) I tried to post a message and it never showed up. I read the gmane FAQ and > it doesn't look like they will be of much help; however ... > > 3) Per http://www.tcpdump.org/#mailing-lists, I tried re-subscribing to the > list > by sending an e-mail to majord...@lists.tcpdump.org. I later received > notification that the message was delayed and had not yet been delivered but > that our mail server would continue to try to deliver the message. > Unfortunately, I later received the failure notification of the message and > that > our mail server stopped trying to deliver it. > > 4) On http://www.tcpdump.org/#mailing-lists, it also indicates that you should > be able to use the web interface[1] to subscribe; however, that never worked > either. > > 5) The message that I tried to post earlier later came back to me as > undeliverable. > > Is anyone else here experiencing trouble with the tcpdump-workers? > > Thanks. > - Chris > > [1]: > https://cod.sandelman.ca/cgi-bin/mj_wwwusr/domain=lists.tcpdump.org?user=&; > passw=&func=lists-long-full&extra=tcpdump-workers > > (NOTE: I had to split the URL over 2 lines; otherwise gmane complains that, > "You have lines longer than 80 characters. Fix that.") > > > ___ > Sent via: Wireshark-dev mailing list > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Wireshark-dev] tcpdump-workers mailing list troubles
On Wed, Apr 18, 2012 at 4:48 PM, abhinav narain wrote: > Please do so. my last two messages bounced back ! The MX for lists.tcpdump.org is cod.sandelman.ca, and it can't be pinged. So, list is down for everybody. Cheers, Sam - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] relation of pcap_setdirection and inbound/outbound filter qualifiers
We'd like to distinguish between ethernet frames received on an interface, and sent, and due to the nature of the traffic, we can't rely on the addressing information in the packets. Currently, we do this with an external tap, that generates seperate pcaps for each direction. Works fine, but needs special hardware. We'd rather just bridge through a multi-port linux server. I note that libpcap has pcap_setdirection(), and someone tried to introduce a -P flag to set it (http://sourceforge.net/tracker/?func=detail&aid=2845468&group_id=53066&atid=469575). Is that because the "host inbound"/"host outbound" qualifiers in the pcap-filter syntax do the same thing? They aren't very well described, what do they mean for packets traversing a bridge setup using linux ebtables? And despite the dire warnings in the docs, is inbound and outbound, pcap_setdirection supported with libpcap 0.8 and Linux >= 3.5? Thanks, Sam ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
