[tcpdump-workers] problem with port numbering
Hello, I am currently facing problems with understanding how port numbering occurs, with pcap_findalldevs(). kindly help me to figure out, how to determine the port numbering through pcap... Thank you. Awaiting your reply - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] problem with port numbering
Hello, > I am currently facing problems with understanding how port numbering > occurs, with pcap_findalldevs(). From the man pages, pcap_findalldevs() constructs a list of network devices that can be opened with pcap_create() and pcap_activate() or with pcap_open_live() > kindly help me to figure out, how to determine the port numbering through > pcap... " determine the port numbering through pcap" of what ??, if you could elaborate on what you are actually trying to actually do, this list might be more helpful. Regards, Harish - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] problem with port numbering
Hai, Pcap_findalldevs() will give the interfaces information, for port number you have to give the port number in filter. Prasanna Kumar.N, IMImobile Plot 770, Rd. 44 Jubilee Hills, Hyderabad - 500033 = This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the sender immediately by e-mail and delete this e-mail from your system. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any attachment with this email. IMImobile, Plot No:770, Road No : 44, Jubilee Hills, Hyderabad, India, 500033. www.imimobile.com == This e-mail message has been scanned for Viruses and Content and cleared by Symantec Mail Security -Original Message- From: tcpdump-workers-ow...@lists.tcpdump.org [mailto:tcpdump-workers-ow...@lists.tcpdump.org] On Behalf Of rajath kumara Sent: Friday, June 03, 2011 12:18 PM To: tcpdump-workers@lists.tcpdump.org Subject: [tcpdump-workers] problem with port numbering Hello, I am currently facing problems with understanding how port numbering occurs, with pcap_findalldevs(). kindly help me to figure out, how to determine the port numbering through pcap... Thank you. Awaiting your reply - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] problem with port numbering
On Jun 2, 2011, at 11:48 PM, rajath kumara wrote: > I am currently facing problems with understanding how port numbering > occurs, with pcap_findalldevs(). What do you mean by "port numbering"? To what sort of ports, and what numbers for them, are you referring here? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [libpcap][patch] appending to a capture
On 1/06/11 12:43 PM, Michael Richardson wrote: "Sam" == Sam Roberts writes: >> Yeah, I'd rather that we have a good set of pcap manipulation >> tools. Maybe we just need better pointers to mergecap and >> editcap? Sam> I don't see extensions to libpcap and a good set of tools as an Sam> either/or thing. Sam> I'd be pretty happy to see the capabilities of tools such as Sam> mergecap, editcap, and tcpslice presented as C callable APIs. So, you'd like to have pcap_reopen() then? I think that if give the function a new name, it will be less surprising to people. pcap_reopen() is a much better idea than that originally posted. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [libpcap][patch] appending to a capture
On 1/06/11 08:10 AM, Mark Johnston wrote: Hi Darren, On Tue, May 31, 2011 at 03:53:22PM -0700, Darren Reed wrote: Hi Mark, I must admit that I don't see the point of this patch. A pcap data file, with packets in it, is something that I would create using tcpdump over a specific period of time. The data file is thus associated with a very specific set of actions. To then append data to that file without that data being associated with the original action seems wrong. In my tree at work, the function in used in a program quite similar to tcpflow. I agree that it doesn't make sense to cat the output of multiple tcpdump sessions into a single capture file, but it depends on what I want to do with the recorded packets... in my case they're used by another program to replay captured flows, so the context in which they were originally captured doesn't really matter. That said, I can also imagine people using this function and running into huge performance problems. I don't see how that is. The function essentially does the following: - Check if we're writing to stdout. If so, write a header and return. - Open the file, read the header and make sure it matches the one passed into the function. - If it does, lseek to EOF, and if the file was empty, write a header. - Return the descriptor. How could this cause a performance problem? Because for every packet that is appended you need to do: 1. open(2) 2. read(2) 3. seek(2) 4. write(2) 5. close(2) That's an awful lot of overhead to write 100 bytes out to a file. My fear is that various people will see this function and end up using it in place of the other functions in libpcap because they like the name of this one. Michael's idea of pcap_reopen() is much better. It supports everything from doing a single packet write to multiple packets with only a single open/read/seek. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] pcap_compile Segmentation Fault
Hi, I am trying to compile a filter but I am getting a segmentation fault,
anyone can help me out?
Code:
"
...
handle = pcap_open_offline(".cap",errbuff);
string filtroexp;
filtroexp = "tcp port 80";
pcap_compile(handle,&filtro,filtroexp.c_str(),0,0);
...
"
Thanks,
--
Flavio Sales Truzzi
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_compile Segmentation Fault
On Jun 3, 2011, at 4:18 PM, Flavio Truzzi wrote:
>handle = pcap_open_offline(".cap",errbuff);
You're missing a
if (handle == NULL) {
report whatever error is in errbuff;
stop;
}
there. What happens after you add it?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [libpcap][patch] appending to a capture
On Jun 3, 2011, at 3:13 PM, Darren Reed wrote: > Because for every packet that is appended you need to do: > 1. open(2) > 2. read(2) > 3. seek(2) > 4. write(2) > 5. close(2) Really? Why can't you do open(2) read(2) seek(2) write(2) in pcap_dump_append(), and then just keep writing packets to the pcap_dumper_t you got back from pcap_dump_append()? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [libpcap][patch] appending to a capture
On Jun 1, 2011, at 12:43 PM, Michael Richardson wrote: > So, you'd like to have pcap_reopen() then? What would pcap_reopen() do? Mark's new API has a reasonable name given what it does: 1) it returns a pcap_dumper_t, not a pcap_t, so it should have "dump" in its name; 2) it opens an existing pcap file for appending, so it should have "append" in its name. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_compile Segmentation Fault
The handle ins't null, if I remove the compile statement I can sniff the
packages ...
On Fri, Jun 3, 2011 at 8:32 PM, Guy Harris wrote:
>
> On Jun 3, 2011, at 4:18 PM, Flavio Truzzi wrote:
>
> >handle = pcap_open_offline(".cap",errbuff);
>
> You're missing a
>
>if (handle == NULL) {
>report whatever error is in errbuff;
>stop;
>}
>
> there. What happens after you add it?
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
>
--
Flavio Sales Truzzi
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [libpcap][patch] appending to a capture
On 3/06/11 05:24 PM, Guy Harris wrote: On Jun 3, 2011, at 3:13 PM, Darren Reed wrote: Because for every packet that is appended you need to do: 1. open(2) 2. read(2) 3. seek(2) 4. write(2) 5. close(2) Really? Why can't you do open(2) read(2) seek(2) write(2) in pcap_dump_append(), and then just keep writing packets to the pcap_dumper_t you got back from pcap_dump_append()? Presumably because the way I read his description of it, it sounded like the verification (matching of file header) was done for each new packet added. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_compile Segmentation Fault
On 3/06/11 04:18 PM, Flavio Truzzi wrote:
Hi, I am trying to compile a filter but I am getting a segmentation fault,
anyone can help me out?
Code:
"
...
handle = pcap_open_offline(".cap",errbuff);
string filtroexp;
filtroexp = "tcp port 80";
pcap_compile(handle,&filtro,filtroexp.c_str(),0,0);
...
"
Thanks,
stack trace?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_compile Segmentation Fault
On Jun 3, 2011, at 4:18 PM, Flavio Truzzi wrote: >pcap_compile(handle,&filtro,filtroexp.c_str(),0,0); Where is filtro defined? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] patch - use BIOCSETLIF when available
Solaris 11 will support the ioctl BIOCSETLIF.
This operates on "struct lifname".
Whilst there are other *LIF ioctls, only this one
is important for libpcap.
For most consumers, the primary difference is the
length of the name allowed. The traditional ifname
structure only allowed for 16 character interface
names. The newer struct lifname allows for 32.
With the presence of interface renaming, amongst
other features, use of the struct lifname ioctls will
be required for proper functionality.
Darren
diff -u libpcap-clone/pcap-bpf.c libpcap/pcap-bpf.c
--- libpcap-clone/pcap-bpf.cFri Jun 3 20:41:15 2011
+++ libpcap/pcap-bpf.c Fri Jun 3 19:47:06 2011
@@ -1459,7 +1459,15 @@
{
int status = 0;
int fd;
+#ifdef LIFNAMSIZ
+ struct lifreq ifr;
+ const char *ifrname = ifr.lifr_name;
+ const size_t ifnamsiz = sizeof(ifr.lifr_name);
+#else
struct ifreq ifr;
+ const char *ifrname = ifr.ifr_name;
+ const size_t ifnamsiz = sizeof(ifr.ifr_name);
+#endif
struct bpf_version bv;
#ifdef __APPLE__
int sockfd;
@@ -1551,9 +1559,8 @@
*/
sockfd = socket(AF_INET, SOCK_DGRAM, 0);
if (sockfd != -1) {
- strlcpy(ifr.ifr_name,
- p->opt.source,
- sizeof(ifr.ifr_name));
+ strlcpy(ifrname,
+ p->opt.source, ifnamsiz);
if (ioctl(sockfd, SIOCGIFFLAGS,
(char *)&ifr) < 0) {
/*
@@ -1667,7 +1674,7 @@
pcap_strerror(errno));
goto bad;
}
- (void)strncpy(ifr.ifr_name, p->opt.source,
sizeof(ifr.ifr_name));
+ (void)strncpy(ifrname, p->opt.source, ifnamsiz);
if (ioctl(fd, BIOCSETIF, (caddr_t)&ifr) < 0) {
snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "BIOCSETIF: %s:
%s",
p->opt.source, pcap_strerror(errno));
@@ -1697,9 +1704,13 @@
/*
* Now bind to the device.
*/
- (void)strncpy(ifr.ifr_name, p->opt.source,
- sizeof(ifr.ifr_name));
- if (ioctl(fd, BIOCSETIF, (caddr_t)&ifr) < 0) {
+ (void)strncpy(ifrname, p->opt.source, ifnamsiz);
+#ifdef BIOCSETLIF
+ if (ioctl(fd, BIOCSETLIF, (caddr_t)&ifr) < 0)
+#else
+ if (ioctl(fd, BIOCSETIF, (caddr_t)&ifr) < 0)
+#endif
+ {
status = check_setif_failure(p, errno);
goto bad;
}
@@ -1726,9 +1737,12 @@
*/
(void) ioctl(fd, BIOCSBLEN, (caddr_t)&v);
- (void)strncpy(ifr.ifr_name, p->opt.source,
- sizeof(ifr.ifr_name));
+ (void)strncpy(ifrname, p->opt.source, ifnamsiz);
+#ifdef BIOCSETLIF
+ if (ioctl(fd, BIOCSETLIF, (caddr_t)&ifr) >= 0)
+#else
if (ioctl(fd, BIOCSETIF, (caddr_t)&ifr) >= 0)
+#endif
break; /* that size worked; we're done
*/
if (errno != ENOBUFS) {
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] patch - configure.in changes for Linux header file detection
This set of diffs is required to correct a problem when compiling libpcap on Solaris 11 due to the assumption that the presence of AF_PACKET implies certain header files are in certain positions. The failure (without the patch) is demonstrated as follows: gcc -O2 -fpic -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))" -g -O2 -c ./fad-getad.c ./fad-getad.c:69:27: linux/types.h: No such file or directory ./fad-getad.c:70:31: linux/if_packet.h: No such file or directory Darren diff -u libpcap-clone/configure.in libpcap/configure.in --- libpcap-clone/configure.in Fri Jun 3 20:41:14 2011 +++ libpcap/configure.inFri Jun 3 20:52:20 2011 @@ -103,6 +103,8 @@ dnl "AC_LBL_FIXINCLUDES" wouldn't work on some platforms such as Solaris. dnl AC_CHECK_HEADERS(sys/ioccom.h sys/sockio.h limits.h paths.h) +AC_CHECK_HEADERS(linux/types.h) +AC_CHECK_HEADERS(linux/if_packet.h netpacket/packet.h netpacket/if_packet.h) AC_CHECK_HEADERS(net/pfvar.h, , , [#include #include #include ]) Only in libpcap: configure.in.mine Only in libpcap: configure.in.orig Only in libpcap: diffs Common subdirectories: libpcap-clone/doc and libpcap/doc Only in libpcap: etherent.o diff -u libpcap-clone/fad-getad.c libpcap/fad-getad.c --- libpcap-clone/fad-getad.c Fri Jun 3 20:41:14 2011 +++ libpcap/fad-getad.c Wed Sep 15 20:08:58 2010 @@ -61,12 +61,16 @@ #endif #ifdef AF_PACKET -# ifdef __Lynx__ -/* LynxOS */ +# ifdef HAVE_NETPACKET_PACKET_H +# include +# endif +# ifdef HAVE_NETPACKET_IF_PACKET_H # include -# else -/* Linux */ +# endif +# ifdef HAVE_LINUX_TYPES_H # include +# endif +# ifdef HAVE_LINUX_IF_PACKET_H # include # endif #endif - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Variable length mac headers and gencode.c (and
On 13/05/11 12:52 AM, Darren Reed wrote:
On 12/05/11 04:27 AM, Guy Harris wrote:
On May 10, 2011, at 1:40 PM, Darren Reed wrote:
To pursue this a little further, experimenting has
determined that the best layout thus far would be
something similar to this:
bits field
00-07 version (1)
08-15 pad (0)
16-31 pre-mac payload length
32-63 dlt (DLT_*)
64-79 ethernet protocol number
80-95 pad (0)
What about packets for which there is no appropriate Ethernet
protocol number value, such as:
various link control protocols for PPP;
management and control frames for 802.11 (and similar frames for
older LAN technologies such as FDDI and Token Ring);
LAN frames with 802.2 headers with DSAPs for which there's no
Ethernet protocol number;
LAN frames with 802.2+SNAP headers with an OUI other than 0x00;
etc.?
An alternative would be like this:
bits field values
-
00-07 version (1)
08-15 control field for bits 64-95
16-31 pre-mac payload length
32-63 dlt (DLT_*)
64-95 mac payload type
So, if bits 08-15 are 0, 64-79 are 0 and 80-95 are the ethernet
protocol number.
...
I've adopted the comments directly above into the frame format being used.
The attached diffs represent the changes required to have libpcap
properly work with this header. As yet I haven't seen a DLT assigned, so
I've chosen one a fair distance off - 16384. At present the code
generator assumes that bits 8-15 are 0 because thus far there is no
other type of packet being generated.
Darren
diff -ur libpcap-clone/bpf_image.c libpcap/bpf_image.c
--- libpcap-clone/bpf_image.c Fri Jun 3 20:41:14 2011
+++ libpcap/bpf_image.c Wed May 11 23:42:42 2011
@@ -130,6 +130,11 @@
fmt = "4*([%d]&0xf)";
break;
+ case BPF_LDX|BPF_MSHM|BPF_B:
+ op = "ldxbi";
+ fmt = "4*([[%d]]&0xf)";
+ break;
+
case BPF_LD|BPF_MEM:
op = "ld";
fmt = "M[%d]";
diff -ur libpcap-clone/gencode.c libpcap/gencode.c
--- libpcap-clone/gencode.c Fri Jun 3 20:41:14 2011
+++ libpcap/gencode.c Fri Jun 3 19:47:06 2011
@@ -1608,6 +1608,14 @@
off_nl = -1;
off_nl_nosnap = -1;
return;
+
+ case DLT_LINK:
+ off_linktype = 8;
+ off_macpl = 0;
+ off_macpl_is_variable = 1;
+ off_nl = 0;
+ off_nl_nosnap = 0;
+ return;
}
bpf_error("unknown data link type %d", linktype);
/* NOTREACHED */
@@ -1776,7 +1784,10 @@
{
struct slist *s, *s2;
- s = gen_off_macpl();
+ if (linktype != DLT_LINK)
+ s = gen_off_macpl();
+ else
+ s = NULL;
if (s != NULL) {
/*
* There's a variable-length prefix preceding the
@@ -1818,8 +1829,13 @@
* of off_mac_pl + off_nl from the beginning of the
* raw packet data.
*/
- s = new_stmt(BPF_LDX|BPF_MSH|BPF_B);
- s->s.k = off_macpl + off_nl;
+ if (linktype == DLT_LINK) {
+ s = new_stmt(BPF_LDX|BPF_MSHM|BPF_B);
+ s->s.k = 2;
+ } else {
+ s = new_stmt(BPF_LDX|BPF_MSH|BPF_B);
+ s->s.k = off_macpl + off_nl;
+ }
}
return s;
}
@@ -2437,6 +2453,39 @@
return (NULL);
}
+static struct slist *
+gen_load_link_ll_header_len()
+{
+ struct slist *s1, *s2;
+
+ if (reg_off_macpl == -1)
+ reg_off_macpl = alloc_reg();
+
+ /*
+* Generate code to load the length of the link header into
+* the register assigned to hold that length, if one has been
+* assigned. (If one hasn't been assigned, no code we've
+* generated uses that prefix, so we don't need to generate any
+* code to load it.)
+*/
+ if (reg_off_macpl != -1) {
+ s1 = new_stmt(BPF_LD|BPF_H|BPF_ABS);
+ s1->s.k = 2;
+ s2 = new_stmt(BPF_ST);
+ s2->s.k = reg_off_macpl;
+ sappend(s1, s2);
+
+ /*
+* Now move it into the X register.
+*/
+ s2 = new_stmt(BPF_MISC|BPF_TAX);
+ sappend(s1, s2);
+
+ return (s1);
+ } else
+ return (NULL);
+}
+
/*
* At the moment we treat PPI as normal Radiotap encoded
* packets. The difference is in the function that generates
@@ -2775,6 +2824,11 @@
case DLT_PPI:
s = gen_load_802_11_header_len(s, b->stmts);
break;
+
+ case DLT_LINK:
+ s = gen_load_link_ll_header_len();
+ break;
+
}
/*
@@ -5685,8 +5739,13 @@
s[i]->s.k = off_macpl + off_nl + 9;
i++;
/* X = ip->ip_hl <<
