[tcpdump-workers] Request for a DLT value (for nflog)
Hi,
== START OF LEGAL NOTES ==
I haven't ready any documentation of nfnetlink, and this information was purely
got
from reading header and source files of Linux kernel, libnfnetlink[1] and
libnetfilter_log[2].
== END :-) ==
!!! All structures are aligned to 4B !!!
DLT_NFLOG starts with struct nfgenmsg header defined in
,
which looks like (changed to stdint.h types + my comments in /** **/):
struct nfgenmsg {
uint8_t nfgen_family; /* AF_xxx */
/** Linux AF-VALUES, AF_INET=2, AF_INET6=10 **/
uint8_t version; /* nfnetlink version */
/** For now only NFNETLINK_V0 = 0 **/
uint16_t res_id; /* resource id */
/** on one socket netlink it's possible to listen to
** several nflog-groups. Value in BIG ENDIAN **/
};
After which follow any numbers of TLVs.
(Structure From header)
struct nfattr {
uint16_t nfa_len; /** length, including 4 bytes of header, host-order
**/
uint16_t nfa_type; /* we use 15 bits for the type, and the highest
*bit to indicate whether the payload is nested */
/** type, host-order */
/** uint8_t nfa_data[nfattr.nfa_len-4] **/
};
Known types are defined in enum nfulnl_attr_type
()
Some of these includes:
- NFULA_PAYLOAD=0x9 /* opaque data payload */
/** nfgen_family payload **/
- NFULA_PREFIX=0xa /* string prefix */
/** prefix (from --nflog-prefix) NUL-terminated */
- NFULA_UID=0xb /* user id of socket */
/** 4B in BE */
- NFULA_GID=0xe /* group id of socket */
/** 4B in BE */
...
Regards,
Jakub Zawadzki.
[1] http://www.netfilter.org/projects/libnfnetlink/
[2] http://www.netfilter.org/projects/libnetfilter_log/
-
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 11:46:50AM -0700, Guy Harris wrote: > And is there any packet data in there? For example, is that what's in > NFULA_PAYLOAD TLVs?- I'm not 100% sure if I undestand your question, but I think yes, it's what current version of pcap-netfilter-linux.c is doing, i.e. finding NFULA_PAYLOAD and passing it to user as DLT_IPV4 Current version of pcap-netfilter-linux.c is binding only for AF_INET so it's ok. But after registring new DLT_ it'd be possible to bind both to AF_INET and AF_INET6. Registring new DLT_ is also needed when you want to store more information about logged packets (like uid/gid/prefix). If you want I can send you example pcap + patch for wireshark. Cheers, Jakub. - 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 01:54:43PM -0700, Guy Harris wrote: > Are these structures likely to remain unchanged (other than new TLV types > being added, > and perhaps some TLVs changing length in a backwards-compatible fashion), so > that older > DLT_NFLOG captures won't be rendered unreadable by code that reads newer > ones, or does > this run the risk of changing into a mess like DLT_PFLOG, where the format > changes in > incompatible fashion, so that code that reads newer captures can't read older > captures?- In nfgenmsg there's version field, but I'm not in netfilter dev team, and can't answer these questions. If DLT_* registration process can be only done by someone who maintains given protocol/interface than I'm not such person :) Cheers, Jakub. - 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 11:17:20PM +0200, Jakub Zawadzki wrote: > If DLT_* registration process can be only done by someone who maintains > given protocol/interface than I'm not such person :) Ping? Cheers, Jakub - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] autoconf and patches
On Sat, Jul 09, 2011 at 10:37:55PM -0400, Michael Richardson wrote: > Just a general comment about patches: > - try not to include "configure" in your patch. From a developer > point of view, this is a generated file, and any patch it generally > big and irrelevant, and just confuses people reading your patch > for actual information. So maybe it should be added to .gitignore? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] rpcap support?
Hi, On Sat, Jul 09, 2011 at 02:36:50PM +0200, Joerg Mayer wrote: > I've created a patch that actually manages to build into an rpm on my > opensuse system. Wireshark HEAD also detects rpcap support when buiding with > cmake. Now all I have to do is wait for the equipment to come back to > do a real test... > The patch can be downloaded from: > http://www-agrw.informatik.uni-kl.de/home/jmayer/rpcap.v2.patch > > I'd really like to receive some feedback on this. This patch is missing all new files like: pcap-remote.[ch], sockutils.[ch] or pcap/remote-ext.h Cheers. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for a DLT value (for nflog)
On Tue, Aug 30, 2011 at 05:56:54PM -0700, Guy Harris wrote: > So how do you know how many TLVs there are? Is there a special "end of list" > TLV? Nope, you should read until end of message (packet). PS: Sorry for late response, and thanks for assigning value :) - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Initializing a device
On Fri, Jan 06, 2012 at 04:47:09PM +0100, Akos Vandra wrote: > Another reason why this is not a good approach: Let's get wireshark in > the picture. Let's say the user selected a canusb device. The only way > for wireshark to know what parameters (ex. baudrate) the canusb device > needs is if wireshark knows how the canusb device works. This is bad. > IMHO one of the main goals of libpcap would be to hide how the capture > device actually works from the user application, so that it can use a > device-independent way of getting packets. IMHO user need to know what parameters he can (or need to) set, and 1/ He can use either enviroment variables, like: CANUSB_BAUDRATE=2400 tcpdump -i canusb0 USBRADIO0_CHANNEL=12 tcpdump -i usbradio0 2/ Capture from interfaces like: tcpdump -i canusb0:baudrate=2400,parity or tcpdump -i usbradio0:channel=12 I used something like (2/) in nflog cause there was no other way, but I agree possibility to add custom parameters would be great, and much more user friendly! > - wireshark repeadetly calls pcap_setparam_int(id, value) or > pcap_setparam_bool(id, value), or whatever, which checks for parameter > type safety, and calls the capture module's pcap_setparam(id, &value). > (Dereferencing will be safe as the API already checked for type > safety. This idea is from the wireshark API, a few basic types will be > supported, like UINT, INT, BOOL, ENUM, etc. Let's have just: int pcap_setparam(pcap_t *p, const char *param, const char *value) If param is not understand, or value is invalid for given param (like: not integer) it should return -1. Regards. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] rpcap
Hi, On Wed, May 16, 2012 at 07:45:53AM +0200, Fulvio Risso wrote: > Just because the code was done in 2002 and probably at that time I used the > old > socket style. Nah, patch 3518553 [1] is mine :) Yours code seems to use getaddrinfo like suggested by Artur. 3518553 is less invasive and more compact reimplementation of winpcap's rpcap, but it doesn't have all features which winpcap version has. (I thought that less invasive version of rpcap could be finally merged to libpcap...) Artur, you probably want to use original rpcap support from winpcap. Either from winpcap sources [2] or from Joerg Mayer git repository[3] Cheers, Kuba. [1] https://sourceforge.net/tracker/?func=detail&aid=3518553&group_id=53067&atid=469579 [2] http://www.winpcap.org/install/bin/WpcapSrc_4_1_2.zip [3] https://github.com/jmayer/libpcap - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] pcap-netfilter-linux: compilation error (bug #3536543)
Hi, Compilation of pcap-netfilter-linux.c is currently broken. I've already reported it in bug #3536543 [1], but I'm not sure if someone read sf tracker nowadays :) gcc -O2 -fpic -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -g -O2 -c ./pcap-netfilter-linux.c ./pcap-netfilter-linux.c:435:1: error: conflicting types for 'nflog_create' ./pcap-netfilter-linux.h:35:9: note: previous declaration of 'nflog_create' was here ./pcap-netfilter-linux.c: In function 'nflog_create': ./pcap-netfilter-linux.c:447:4: error: 'is_ours' undeclared (first use in this function) ./pcap-netfilter-linux.c:447:4: note: each undeclared identifier is reported only once for each function it appears in make: *** [pcap-netfilter-linux.o] Error 1 Regards, Jakub. [1] http://sourceforge.net/tracker/?func=detail&aid=3536543&group_id=53067&atid=469577 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap and PF_RING
On Thu, Aug 30, 2012 at 11:10:02AM -0700, Jim Lloyd wrote: > I'm confused as to what is required for libpcap to use PF_RING. Most of the > hits I have seen while searching for this are ancient and refer to libpcap > 0.8. Can anyone please provide a link or summarize what must be done for > libpcap to use PF_RING on a relatively modern Linux x86_64 system. I am in > particular interested in RHEL5/6. https://svn.ntop.org/svn/ntop/trunk/PF_RING/doc/UsersGuide.pdf page 12-16 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap and struct canusb_t, src: failure on debian/ubuntu
On Mon, Sep 03, 2012 at 02:34:02PM -0400, Michael Richardson wrote:
> The changes introduced in June to deal with "canopy" being picked up
> by CANusb interface, introduced a problem:
>
> ./pcap-canusb-linux.c:260:20: error: 'struct canusb_t' has no member named
> 'src'
> make: *** [pcap-canusb-linux.o] Error 1
canusb_t->src was removed in 2426611584e9099af5f98d18ef37337df9bef025.
> I'm not sure what libraries pcap-canusb-linux.c is expecting.
> Perhaps we need to have ./configure notice that the libusb-dev is the
> wrong one and not configure CANUSB?
Maybe no special libraries required, we just need to restore canusb_t->src,
or variant of it, attaching sample patch.
Can you test if it compiles?
diff --git pcap-canusb-linux.c pcap-canusb-linux.c
index 2e26f6e..b84f884 100644
--- pcap-canusb-linux.c
+++ pcap-canusb-linux.c
@@ -77,6 +77,7 @@ struct canusb_t
{
libusb_context *ctx;
libusb_device_handle *dev;
+char *serial;
pthread_t worker;
int rdpipe, wrpipe;
volatile int* loop;
@@ -264,7 +265,7 @@ static void* canusb_capture_thread(struct canusb_t *canusb)
libusb_init(&ctx);
-serial = canusb->src + strlen(CANUSB_IFACE);
+serial = canusb->serial;
dev = canusb_opendevice(ctx, serial);
fcntl(canusb->wrpipe, F_SETFL, O_NONBLOCK);
@@ -357,7 +358,8 @@ static int canusb_activate(pcap_t* handle)
handle->linktype = DLT_CAN_SOCKETCAN;
handle->set_datalink_op = NULL;
-serial = handle->opt.source + strlen("canusb");
+serial = handle->opt.source + strlen(CANUSB_IFACE);
+canusb.serial = strdup(serial);
canusb.dev = canusb_opendevice(canusb.ctx,serial);
if (!canusb.dev)
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
