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
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
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:
>
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 injec
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
> o
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)
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 complainin
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
th
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
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
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
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 ubun
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 yo
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.
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 pack
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
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
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 lab
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/bis
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 submit
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.
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 p
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
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.
I
24 matches
Mail list logo
