gmane.network.tcpdump.devel

Request for DLT

Anders Broman — 2013-05-14T07:56:42

Hi,
I would need a DLT for a wrapper around higher level PDU's or per-packet DLT:s the format is multipurpose and consists of a number of TLV:s proceeding the actual PDU.
There are TLV:s which describes which protocol the PDU is and meta data such as IP address and port (if the transport protocol(s) are striped off).

The format can be used by logging functions in various nodes, say after deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc.
Tag values and an outline of the format can be found here http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup

Best regards
Anders Broman
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers< at >lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Request for new DLT

Anders Broman — 2013-05-16T14:02:02

Hi,
I would need a DLT for a wrapper around higher level PDU's or per-packet DLT:s the format is multipurpose and consists of a number of TLV:s proceeding the actual PDU.
There are TLV:s which describes which protocol the PDU is and meta data such as IP address and port (if the transport protocol(s) are striped off).

The format can be used by logging functions in various nodes, say after deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc.
Tag values and an outline of the format can be found here http://anonsvn.wireshark.org/viewvc/trunk/epan/exported_pdu.h?revision=49285&view=markup

LINKTYPE_ANY_PDU or something like that?

Best regards
Anders Broman
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers< at >lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Request for new pcap/pcapng DLT Format

2013-05-13T20:04:37

Hi, I would like to request a custom DLT type for the Schweitzer 
Engineering Laboratories "RTAC" product.  Information on the 
product/purpose of the DLT is included below:

The RTAC product family (SEL-3530, SEL-2241, SEL-3505) is a Linux-based 
Automation Controller product that is capable of interfacing with SEL and 
3rd-party equipment using a variety of standard industrial protocols such 
as SEL FM, DNP3, Modbus, C37.118, Telegyr 8979 and others. Each protocol 
instance (master/client or slave/server) is configured to utilize either 
Ethernet or EIA-232/485 serial connectivity with protocol variations for 
each medium taken into account.  More information is available at 
www.selinc.com/sel-3530

The configuration software for the RTAC platform is named AcSELerator RTAC 
(SEL-5033) and is used to set up all communications and user logic for the 
controller as well as provide downloading and online debugging facilities. 
 One particularly useful aspect of the online debugging capabilities is a 
robust C

capturing only timestamp excluding otherinformation

achyut baruah — 2013-05-09T05:51:21

Sir, I have been using Tcpdump. Extracting timestamp from a pcap file is
quite easy. Is there any way to capture only the timestamp excluding other
info using Tcpdump while capturing packet.

Request for new DLT

Pascal Quantin — 2013-05-18T18:45:19

Hi all,

Anders Broman, Wireshark core developer, is currently designing an export
functionality for PDUs and would need a DLT allocated for this new
functionality.
You will find below the email he tried to send to this mailing list a few
days ago and that got bounced. I hope mine will go through :)

Best regards,
Pascal.

-----Original Message-----
From: Anders Broman
Sent: den 16 maj 2013 16:04
To: 'tcpdump-workers< at >lists.tcpdump.org'
Subject: RE: Request for new DLT


Hi,
I would need a DLT for a wrapper around higher level PDU's or per-packet
DLT:s the format is multipurpose and consists of a number of TLV:s
proceeding the actual PDU.
There are TLV:s which describes which protocol the PDU is and meta data
such as IP address and port (if the transport protocol(s) are striped off).

The format can be used by logging functions in various nodes, say after
deserialization(SS7 over TDM) decryption(GSM/UMTS/LTE Nodes?) etc.
Tag values and an outline of the format can be found here
http://anonsvn.wireshark.org/vi

DLT for Bluetooth Low Energy

dragorn — 2013-05-16T14:12:07

The list seems to be rejecting some posts, I just unsubbed/resubbed
myself in the hopes that it wakes up and lets me post this time; it
also bounced Mike Ryans post and he asked me to send it along.

----- Forwarded message from Mike Ryan <mikeryan< at >isecpartners.com> -----

Date: Mon, 29 Apr 2013 13:09:32 -0700
From: Mike Ryan <mikeryan< at >isecpartners.com>
To: dragorn< at >kismetwireless.net
Subject: request: DLT for Bluetooth Low Energy

[sent this as-is to tcpdump-workers< at >lists.tcpdump.org]

I would like a DLT for Bluetooth Low Energy, which is described in the
following document (warning, large PDF):

    https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737

The link layer specification begins on PDF page 2189. The packet format
and headers begin on page 2200.

Background: I am a security researcher and have implemented a BTLE
sniffer for project Ubertooth (http://ubertooth.sf.net). One of my tools
dumps captured packets to PCAP, currently using USER_DLT0. I have also
written a Wireshark proto

using tcpdump

Mahmood Naderan — 2013-05-16T13:16:03

Hello all users
I am using scientific linux 6.3 which kernel 2.6.32-279.5.1.el6.x86_64. The chassis, say 'A', has 3 network interfaces. Eth1 has valid IP and is connected to internet and eth2 has invalid IP and is connected to another local switch.

Problem is that the internet is randomly disconnected on eth1 so the computer is unreachable through ping command. At the same time, there is another chassis, say 'B', which has also the same configuration. I mean one interface of 'B' is connected to the internet (same internet witch as 'A') and one interface to local switch (same local switch as 'A'). However 'B' uses Ubuntu 12.04.

The internet connection is steady and that means while 'A' is unreachable, 'B' can be pinged.

The situation is very very random, so I tried to use "tcpdump -vvv -i eth1" to see if I can find any useful information about connect/disconnect messages.

Can tcpdump help me with this problem? Any feedback is appreciated.

 
Regards,
Mahmood
______________________________________________

radiotap header retry

ilaria cianci — 2013-05-15T13:54:38

Hi all,

    I have a question about the radiotap header  802.11.

Is there in tcpdump a corresponding filter as wlan.fc.retry==1 in wireshark?

Thanks a lot

Ilaria
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers< at >lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

website not updated

Wesley Shields — 2013-05-15T13:36:06

If tcpdump 4.4.0 and libpcap 1.4.0 are done should the webpage be
updated or are they in some kind of beta form? I'll happily fix it on
github if that's the right place to do it.

Use of critical section on Win32

Gisle Vanem — 2013-05-14T15:21:34

I really don't understand the motivation behind the Win32-code
for pcap_compile(). In gencode.c:

int
pcap_compile(pcap_t *p, struct bpf_program *program,
      const char *buf, int optimize, bpf_u_int32 mask)
{
 int result;

 EnterCriticalSection(&g_PcapCompileCriticalSection);

 result = pcap_compile_unsafe(p, program, buf, optimize, mask);

 LeaveCriticalSection(&g_PcapCompileCriticalSection);
 
 return result;
}

----------

Why doesn't other libpcap functions needs this critical-section protection
too? 

And how about the case when DllMain() hasn't been called (because libpcap
is used as a static lib) and someone calls e.g. pcap_compile(). Then this 
'g_PcapCompileCriticalSection' struct is left un-initialised and the program 
will crash.

Can we maybe sprinkle calls to 'wsockinit()' where needed and let 'wsockinit()'
do it's task only once? I could make the needed patches if we agree on this.

--gv
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers< at >lists.tcpdum

Link-Layer Header Types request for Android

2013-05-14T09:00:15

Hello,

I would like to request a new link-layer header type values:
LINKTYPE_ANDROID_ADB
DLT_ANDROID_ADB

LINKTYPE_ANDROID_LOGGER
DLT_ANDROID_LOGGER

First is ADB. Android Debug Bridge is protocols used to manage Android platforms (connect, send command, receive data). Please check also Android documentation: http://developer.android.com/tools/help/adb.html
For example: There are commands like: OKAY, WRTE (write),  CLSE (close), etc. They can be dissected, for example in Wireshark.

Second: Android Logger (knowns as Logcat logs) is format of (debug, for analyse of issues) Android processes messages.  Logger is something like Linux kernel messages or/and syslog.
You can see implementation on Wireshark side - it can be useful to understand this request:  
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8279

Main purpose of Logger: add system logs allow to analyse application/protocols issues. (example: file over Bluetooth is not send and there is logcat log "socket not open: permission denied")
Main purp

Missing packet fields in big endian with ath9k

Luis Correia — 2013-04-26T14:29:17

Hi all!
I'm doing a project of mine. It's about guiding a robot in my living room using wifi.
At first I tried to use two raspberry pi with a wifi dongle (ath9k-htc) and libpcap to capture wifi packets and read the rssi from my robot mac address.
It works fine. But then I thought in using OpenWRT. Since I was able to get my hands on two cheap TP-LINK MR-3220 (ath9k) I recompiled the code to run on mips.


The thing is all the info I gather from the packets are "like misaligned". For example, if I print the mac address's for each packet I get :

11:96:77:3c:38:e7, d8:d8:b2:94:58:98, 35:8e:ad:e4:a0:4a

where the mac from the robot is 38:e7:d8:d8:b2:94!

And the rest of the bits in the collected packets are also off..
So, the code prints everything fine in the Raspberry Pi (RSSI, type and subtype of frames, etc), why not in openwrt?!


My headers go like this:

#define EXTRACT_LE_16BITS(p) ((u_int16_t)((u_int16_t) * ((const u_int8_t *)(p) + 1) << 8 | (u_int16_t)*((const u_int8_t *)(p) + 0)))


struct sniff_8021

parent-child process,selectable file descriptor and pcap

wen lui — 2013-04-18T02:10:55

I have a program, part of the source codes are:

        handle = pcap_open_live(dev, BUFSIZ, 0, 0, errbuf);
        pcap_compile(handle, &fp, filter_exp, 0, mask) == -1
        pcap_setfilter(handle, &fp);
        struct pcap_pkthdr pcap_header;      // The header that pcap gives
us
        const u_char *pcap_packet;           // The actual packet

        while(1){

          n=fork();
          if(n==0) { // child process
                fd_set rdfds;
                int pcap_fd = pcap_get_selectable_fd(pcap_handler);
                for(;;){
                        FD_ZERO(&rdfds);
                        FD_SET(pcap_fd, &rdfds);
                        FD_SET(sd_proxy, &rdfds);   // here is another fd

                        select(pcap_fd>sd_proxy?pcap_fd+1:sd_proxy+1,
&rdfds, NULL, NULL, NULL)

                        if(FD_ISSET(pcap_fd, &rdfds)) {
                                pcap_packet = pcap_next(pcap_handler,
&pcap_header);
                                if(pcap_packet !=NULL)

(no subject)

wen lui — 2013-04-18T01:56:46

        handle = pcap_open_live(dev, BUFSIZ, 0, 0, errbuf);
        pcap_compile(handle, &fp, filter_exp, 0, mask) == -1
        pcap_setfilter(handle, &fp);
        struct pcap_pkthdr pcap_header;      // The header that pcap gives
us
        const u_char *pcap_packet;           // The actual packet

        while(1){

          n=fork();
          if(n==0) { // child process
                fd_set rdfds;
                int pcap_fd = pcap_get_selectable_fd(pcap_handler);
                for(;;){
                        FD_ZERO(&rdfds);
                        FD_SET(pcap_fd, &rdfds);
                        FD_SET(sd_proxy, &rdfds);   // here is another fd

                        select(pcap_fd>sd_proxy?pcap_fd+1:sd_proxy+1,
&rdfds, NULL, NULL, NULL)
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers< at >lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces

abhinav narain — 2013-04-17T22:57:01

hi everyone,
I have written my own data collection tool, for custom needs using
libpcap for wireless interfaces(2.4,5 GHz) on a router.

I could not find any flag in tcpdump that i can collect only x
number of mgmt packets, y number of control packets and
the rest data packets.

The issue i face is this :
When I run two instances of tcpdump on each interface, it has 5-10% cpu
usage
on the router.
When I use my tool written using libpcap:
When I run it on one interface (say 2.4 GHz), I get 5-10% CPU usage (output
on top),
but when I run another instance of the tool on the other interface(5 GHz
lets say),
both the processes start eating 100% of CPU all the time.

Can someone explain this behavior ?
I was thinking, if both the process's recv() call was spinning on some
shared
resource (buffer)/some kernel thread ... but why does that not happen for
tcpdump ?
I have literally read tcpdump/pcap code before, but I hadn't notice anything
special.
Can someone help me debug this problem ?

Link-Layer Header Type request for Linux KernelMessages

2013-04-17T10:59:42

Hello,

I would like to request a new link-layer header type value:
LINKTYPE_DEV_KMSG_LINUX
DLT_DEV_KMSG_LINUX

and

LINKTYPE_KLOG_LINUX
DLT_KLOG_LINUX

Linux Kernel Message can be captured on Linux by /dev/kmsg and klogctl. Kernel logs can be useful for analysis Linux and network(etc.) behaviour.
Test patch for libpcap for /dev/kmsg is prepared, so you can test it: https://github.com/MichalLabedzki/libpcap/commit/c671673753bba413fe3fc839425162d682289bec (works kernel >= 3.5 and /dev/kmsg, patch need some fixes to check that)

Capture format specification is available at:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/ABI/testing/dev-kmsg

Linux logs can be dissected by Wireshark to improve readability/filtering.

There is also klogctl (http://linux.die.net/man/3/klogctl) and /proc/kmsg - but there is different format. So another Linktype can be add.


Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------

moves to github

Michael Richardson — 2013-04-16T02:40:09

1) we have created github.com/the-tcpdump-group.  It has copies
   of three repositories:
   a) libpcap
   b) tcpdump
   c) tcpdump-htdocs

   These are pushed by a nightly cron job from our master machine.
   So no, github is not the golden or only copy.

   Creating a group means that more people than just I can handle
   merges.  Please contact me if you'd like to help.

2) Guy Harris has run a source 2 github python script to transfer issues
   from SF to github.  They are at:
   https://github.com/the-tcpdump-group/tcpdump/issues
(103 open, 199 closed)

   https://github.com/the-tcpdump-group/libpcap/issues
(116, 173 closed)

   We need help going through these issues.
   I think we can probably come up with some markup to indicate what
   is what, and I see colours and other stuff to help sort things out.
   Tell me your github ID, and I'll add you to the team if necessary.

   There are lots of patches, turning them into pull requests would be
   great.  Many of them are likely already done.

3) we

autoconf 2.61 versus 2.68

François-Xavier Le Bail — 2013-04-13T10:01:09

Hello,

Tha last configure file is "Generated by GNU Autoconf 2.61.".

The previous was "Generated by GNU Autoconf 2.68.".

Is there any risks of regression ?

Francois-Xavier

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers< at >lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Hardlings and absolute paths

Flemming H. Sørensen — 2013-04-12T16:45:05

Hello,

While building libpcap and tcpdump on Pyro, I noticed something in libpcap/Makefile.in; You're using hard links, and absolute paths.

Hardlinks: This may work well on most systems, but our native filesystem doesn't support hardlinks, so it would really be appreciated, if it was changed to symlinks. You already use symlinks in other places.

Absolute paths: This may work well, if every individual users builds it, and installs directly to the location in which they want it. I do, however, feel it would be nice to have relative paths, so the package can be moved around. You already use relative paths in other places.

As the mentioned issues are only affect the man(3) pages, the suggested changes shouldn't cause any unforeseen problems.

I hope you will take my suggestions under advisement. Patch attached.


Best regards
Flemming H. Sørensen
The Pyro OS Team
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers< at >lists.tcpdump.org
https://lists.sande

some questions about libpcap ,especially with fork() called

wen lui — 2013-04-07T22:25:47

 I want to use libpcap to capture some packets in my tcp server program
some of the snippets in my program are like:


        handle = pcap_open_live(dev, BUFSIZ, 0, 0, errbuf);
        pcap_compile(handle, &fp, filter_exp, 0, mask) == -1
        pcap_setfilter(handle, &fp);
        struct pcap_pkthdr pcap_header;      // The header that pcap gives
us
        const u_char *pcap_packet;           // The actual packet

        // proxy server listen, waiting for receiver's tcp request
        listen(listenfd, 1024);
        connfd = accept(listenfd, (struct sockaddr *)&sender_addr,
&sock_len);
        pcap_packet = pcap_next(handle, &pcap_header);

        pid=fork();
        if(pid=0)  // child process
         {
          pcap_packet = pcap_next(handle, &pcap_header);
         }
         blabla.....


listenfd is binding port 3000
my questions are:

1 I don't know how pcap handler works, my understanding is: when
pcap_open_live() function is called and the filter is set, it will capture
all matching packets

[Patch] fad-win32.c

Gisle Vanem — 2013-04-04T08:20:48

This is a similar patch to the change of pcap-dos.c:
  https://github.com/mcr/libpcap/commit/73b5f0387199fbaa75130837b931faf770471640

I.e. the '_interfaces' suffix got lost in some other change to the puplic API.
(I don't know when). Since 'pcap_findalldevs()' is now a more generic version in 
pcap.c, the platform-specific function is called 'pcap_findalldevs_interfaces()' in 
fad-win32.c:

--- Git-Latest\fad-win32.c      Wed Nov 28 23:41:44 2012
+++ fad-win32.c     Wed Mar 27 16:14:02 2013
< at >< at > -216,13 +216,13 < at >< at >
  * Win32 implementation, based on WinPcap
  */
 int
-pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf)
+pcap_findalldevs_interfaces(pcap_if_t **alldevsp, char *errbuf)
 {
        pcap_if_t *devlist = NULL;
        int ret = 0;
        const char *desc;
        char *AdaptersName;
-       ULONG NameLength;
+       ULONG NameLength = 0;
        char *name;

        if (!PacketGetAdapterNames(NULL, &NameLength))

-----

'NameLength = 0' is just in case 'PacketGetAdapterNames()' fails
w/o setting '*