Re: [tcpdump-workers] bad soname for libpcap.so.1.6.2 ?
On May 06 17:37:51, rfranco...@debian.org wrote: > > is normal that soname of libpcap.so.1.6.2 is libpcap.so.0.8 ? > This is specific to Debian and its derivatives, for more details see: > https://people.debian.org/~rfrancoise/libpcap-faq.html And it's /usr/lib/libpcap.so.8.1 on current OpenBSD http://www.openbsd.org/faq/ports/specialtopics.html#SharedLibs ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] PCAP performance
Hi! I have written a packet sniffer under C++ using libpcap. Now I have noticed that about every 3 minutes and 15 seconds the Program uses 100 % of the CPU. After about 45 sec the program works normal again and uses only 10% of the CPU time. The program is running on a 300 MHz Celeron with 128 MB RAM under Slackware 8.1. I also tried it under a 1600 Athlon XP with 512 MB RAM under SuSeE 8.2. There was the same behaviour, except that it only used 80% of the CPU and it was back normal faster. I use libpcap 0.8.1 and pcap_dispatch, which is called in a while statement of a pthread, with 1 as parameter for number of packets to capture. I first thought that I made a mistake in the call-back function, but I replaced my code with return and it did the same thing. I tested the program with hping2 and sent a packet every 10 ms. The used filter is quite long and consists of about 150 pairs of IP-Addresses and Ports. Please help Hans Klute -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] PCAP performance
> > I have written a packet sniffer under C++ using libpcap. > > Now I have noticed that about every 3 minutes and 15 seconds the Program > > uses 100 % of the CPU. > > After about 45 sec the program works normal again and uses only 10% of > the > > CPU time. > > Sure sounds like a problem with your program - as far as I know there > is nothing in libpcap which would cause this. > > > The program is running on a 300 MHz Celeron with 128 MB RAM under > Slackware > > 8.1. > > I also tried it under a 1600 Athlon XP with 512 MB RAM under SuSeE 8.2. > > There was the same behaviour, except that it only used 80% of the CPU > and it was > > back normal faster. > > I use libpcap 0.8.1 and pcap_dispatch, which is called in a while > statement > > of a pthread, with 1 as parameter for number of packets to capture. > > I first thought that I made a mistake in the call-back function, but I > > replaced my code with return and it did the same thing. > > I tested the program with hping2 and sent a packet every 10 ms. The used > > filter is quite long and consists of about 150 pairs of IP-Addresses and > Ports. > > A packet every 10 ms is only 100 pps - this should be no problem at > all. If I test tcpdump on a FreeBSD/Pentium 700 MHz machine with 100 > pps, I see less than 1% load from running tcpdump. I recommend that > you test tcpdump on your system with the same filter as your C++ > program and see what happens. If you do "tcpdump -nw /dev/null" you > have removed all DNS lookups and all writing to the terminal, and > should be left with the load from tcpdump/libpcap itself. It is correct that the performance of tcpdump is better, but it shows the same behaviour but not that strong. Also about every 3 minutes the the idle time of the CPU goes down to 62 percent. It is back at normal within 15 sec (values from top ). It seems to me that somehow libpcap "hangs" a moment, and because my program processes whole packets (snaplen 1500) it takes some time and CPU power to get the queue of packtes empty. Hans > > Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] > -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] PCAP performance
> On Thu, Apr 01, 2004 at 02:12:35PM +0200, Hans Klute wrote: > > Now I have noticed that about every 3 minutes and 15 seconds the Program > > uses 100 % of the CPU. > > After about 45 sec the program works normal again and uses only 10% of > the > > CPU time. > > The program is running on a 300 MHz Celeron with 128 MB RAM under > Slackware > > 8.1. > > If you're running it from a terminal window, try typing the quit > character at it (control-backslash, unless you or the Slackware folks or > Linux distributions in general change it from the traditional UN*X > default) when it's running at 100%; that should cause it to dump core. > Then use gdb to see what the program was doing at that time. > I have tried it, but it didn`t help me very much. The program was in a normal state in which it processed a packet. I realized now that just before my program uses all CPU time the system starts to use the CPU more. The System uses about 30 % of the CPU and then my program starts to burn CPU power. I think there is something happening in the kernel... ? -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] PCAP - IP Fragments
Hi! I just realized a bug/feature of pcap that I didn´t think of. I wrote a sniffer based on pcap. This sniffer can handle fragmented IP packets. Now I realized that if you set up a filter with a UDP or TCP port, you will not get the additional fragments, because in these packets there are no UDP/TCP headers present from which you can get a port number. So I want to ask if it is possible to modify pcap behaviour and where to start. You can tell that a packet should be passed up if the ID in the IP header matches, the problem of course is if a fragment arrives before the first packet. I would prefer a modification in pcap, instead of the sniffer, regarding performance. Any suggestions? hklute -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] PCAP - IP Fragments
> In some email I received from Hans Klute, sie wrote: > [ Charset ISO-8859-1 unsupported, converting... ] > > Hi! > > > > I just realized a bug/feature of pcap that I didn?t think of. > > I wrote a sniffer based on pcap. This sniffer can handle fragmented IP > > packets. Now I realized that if you set up a filter with a UDP or TCP > port, > > you will not get the additional fragments, because in these packets > there > > are no UDP/TCP headers present from which you can get a port number. So > I > > want to ask if it is possible to modify pcap behaviour and where to > start. > > You can tell that a packet should be passed up if the ID in the IP > header > > matches, the problem of course is if a fragment arrives before the first > > packet. I would prefer a modification in pcap, instead of the sniffer, > > regarding performance. > > > > Any suggestions? > > You could write a BPF expression to match a particular packet id#. > How should I do this? I don`t know a specific packet id. What I would have to do is to compare each packet id with the ones received earlier and I must store it to compare with ones received later. With that whole packets must be stored over a longer period. This is not possible!? How does tcpdump handle this? Hans -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Request for new DLT value for Wireshark Dissector
Hi, I´ve written a dissector (MUX27010) for wireshark and I want to commit it to the project. Therefore I need a new DLT value for this dissector/protocol because the protocol doesn´t base upon another data link layer protocol. What the dissector does: It analyses a multiplexed communication between a GSM modem and the host, whereby the multiplexing is based upon the specification 3G TS 27.010. Could you please assign a DLT value for this MUX27010 dissector? Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes: > > > On Jan 10, 2011, at 6:16 AM, Schemmel, Hans-Christoph wrote: > > > I´ve written a dissector (MUX27010) for wireshark and I want to commit it to the project. Therefore I need > a new DLT value for this dissector/protocol because the protocol doesn´t base upon another data link > layer protocol. > > What the dissector does: It analyses a multiplexed communication between a GSM modem and the host, > whereby the multiplexing is based upon the specification 3G TS 27.010. > > So does a packet begin with the address field, as described by TS 27.010 section 5.2.1.2, followed by the > section 5.2.1.3 control field, followed by the information field if present? (Or does it, for example, > include the flag octets - in which case the packet contents presumably escape that octet value - or do > something else? > A packet begins with a flag (octet 0xF9, section 5.2.1.1), followed by address and control field. The dissector is based upon the specification but there are slight deviations to meet the actual implementation of Cinterion and Siemens modules, e.g. no I frame support, but an additional UIH_E frame. Regards, Hans-Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
> Is this DLT value only for the Basic Option, or is it also used for the Advanced Option? If it's also for the > Advanced Option: > > 1) Is the flag octet 0x7E if the Advanced Option is being used? > > 2) If the Advanced Option is being used, do the packet contents include escape octets, or has de-escaping > already been done? The DLT will be used for Basic and Advanced Option, but the multiplexer protocol doesn´t distinguish between Basic and Advanced Option and every packet begins with the 0xF9 flag. The protocol implements the Basic Option with the additional feature of the Error Recovery Mode, which is a subset of the GSM 07.10 Advanced Option. > > Do frames include the FCS? Yes, the checksum is included in the frame. > > Presumably I-frame support could be added without breaking dissection of other captures? > > > Does the control field for those frames have a value that doesn't collide with any values specified in TS > 27.010, so that dissecting UIH_E frames won't break dissection of any frames that conform to TS 27.010?- The control type of the UIH_E frame is coded as I frame, so they could be a collision with TS 27.010. Concerning dissecting: The communication between GSM modem and the host is captured with an USB Tracer. The tracer uses a proprietary format for the trace files, but the data of these files can be exported, e.g. as csv file. I´ve written a parser to process the files and to write the data in a pcap file. In front of a captured multiplexer packet the parser writes an additional header of variable size. This header contains information about the frame direction and (optional) splitted packets inside of the multiplexer frames, e.g. splitted PPP packets in the payload. This information is needed to reassemble splitted packets in the dissector. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes: > > OK, so it sounds as if this isn't raw standard 27.010 traffic. Is MUX27010 likely to be used as a name for that > traffic? If not, we could call it DLT_MUX27010/LINKTYPE_MUX27010. > > What is the format of the additional header?- > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. > > Ok, LINKTYPE_MUX27010 sounds good for me. Thank you! Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes: > > What is the format of the additional header?- The format of the additional header is: | Header_Size | Msg_ID | Freq_ID | Start_Pos | End_Pos | Flag | ... | Msg_ID | Freq_ID | Start_Pos | End_Pos | Flag | Direction | MUX_Frame Header_Size (1 Octet): Total length of the addtional header Msg_ID (1 Octet): ID of the PPP packet Freq_ID (1 Octet): ID of the PPP packet part, if the PPP packet is split into several parts Start_Pos (1 Octet): Beginning of the PPP packet in the information field of the MUX frame End_Pos (1 Octet): End of the packet in the information field Flag (1 Octet): If "Flag" is set, this is the last part of the fragmented/split packet Direction (1 Octet): Direction of the Mux frame: GSM Modem -> Host or Host -> GSM Modem - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes: > > So are any of those fields optional? For example, is the fragment ID optional? If so, what indicates whether > it's present? If nothing is optional, why is the header size not always 7? > The size of the header depends on the number of PPP packets in the payload of the MUX frame. The Header_Size indicates whether Msg_ID, Freq_ID, Start_Pos, End_Pos, and Flag are present. For example: The header of a frame without PPP packet is | Header_Size (=0) | Direction | MUX_Frame The header of a frame with one PPP packet is | Header_Size | Msg_ID | Freq_ID | Start_Pos | End_Pos | Flag | Direction | MUX_Frame The header of a frame with two PPP packet is | Header_Size | Msg_ID | Freq_ID | Start_Pos | End_Pos | Flag | Msg_ID | Freq_ID | Start_Pos | End_Pos | Flag | Direction | MUX_Frame Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes: > OK, so the Direction field and Header_Size fields are always present, and the Header_size field gives the > size of the *optional* fields; if a frame contains N PPP packets, the Header_Size field has the value 5N. > (If Header_Size isn't a multiple of 5, the frame is presumably invalid.) > I´ve mixed up some field sizes in my previous mail. Msg_ID and Freq_ID have a size of 2 octects, not 1 octect like the other fields, sorry. So the optional part has a size of 7 octects. But your conclusion is correct: The Header_Size is multiple of *7*, if there is a frame with N PPP packets, Header_Size is multiple of 7. If it is not multiple of 7, the frame is not valid. Direction field and Header_Size fields are always present. > > Presumably, if the Start_Pos and End_Pos of one packet overlap the Start_Pos and End_Pos of another > packet, the frame is invalid. Yes, that´s correct. > If there are parts of the MUX_Frame that don't correspond to any packet, is > the frame invalid? > (If so, Start_Pos and End_Pos could presumably be replaced by a length field, and the > only "frame is invalid" case there would be if a frame ran past the end of the MUX_Frame, or the packet were > too short to be a PPP packet.)- > It is possible that a valid Mux_frame (with PPP_frames as payload) has parts that don´t correspond to a PPP packet. Two examples: (1) At the beginning of a PPP connection, a Mux_frame with "CONNECT" (AT mode) and the first PPP packet. (2) A Mux_frame with a LCP Terminate packet (PPP) and a "NO CARRIER" packet (AT mode). Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes: > > OK, so it's: > > Header_Size: 1 octet > > A sequence of zero or more instances of: > > Msg_ID: 2 octets > > Freq_ID: 2 octets > > Start_Pos: 1 octet > > End_Pos: 1 octet > > Flag: 1 octet > > Direction: 1 octet > > MUX_Frame: the rest of the packet > Yes, that´s correct. > OK, so presumably the parts that don't correspond to a PPP packet would be the "holes" in the MUX_Frame > field, i.e. the parts that don't correspond to any of the PPP packets described by Start_Pos and End_Pos. > How should those parts be interpreted (if at all)? > The parts that don´t correspond to a PPP packet are AT commands or responses (like "ATI", "AT+CSQ" or "+CSQ: 18,99"). This content is interpreted and displayed as raw text in the Wireshark subtree for the payload/information of a packet. These commands and responses don´t need to be dissected. Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes: > should I just describe the holes as "other data", so you're not > constrained to forever make them all be AT command/response text, or is it guaranteed (now and forever) to > be AT-command-or-response text?- The description of the holes as "other data" sounds good for me. Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes: > > Start_Pos and End_Pos are relative to the beginning of MUX_Frame, right? I.e., a 4-byte chunk starting at > the beginning of MUX_Frame would have a Start_POS of 0? Would End_POS be 3 (meaning that it's the offset of > the last byte of the chunk) or 4 (meaning that it's the offset one byte *after* the last byte of the chunk)? > Yes, Start_Pos and End_Pos are relative to the beginning of the MUX_Frame, but a PPP chunk does not start directly at the beginning of a MUX_Frame (Start_Pos=0). The PPP frame starts after the header fields of the MUX_Frame. I.e. if we have 4 octets for the MUX_Frame header (flag, address, contol & length) and a 4-byte PPP chunk, Start_Pos would be *5* (the 5th byte in the MUX_Frame is the first byte of the PPP frame) and End_Pos would be *8* (the 8th byte in the MUX_Frame is the last byte of the PPP frame). Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
Guy Harris alum.mit.edu> writes:
>
> The PPP chunks are indicated by the {Msg_ID, Freq_ID, Start_Pos, End_Pos,
Flag} quintuplets, where
> Start_Pos is the 1-origin index (i.e., the first byte of the MUX_Frame has an
index of 1, not 0), from the
> beginning of MUX_Frame, of the first byte of the chunk, and End_Pos is the
1-origin index, from the
> beginning of MUX_Frame, of the last byte of the chunk.
>
> All the chunks of a given PPP packet have the same Msg_ID value.
That´s correct.
>
> Is Freq_ID a sequence number for the chunks in a PPP packet? I.e., is the
Freq_ID for the N+1st chunk equal to
> the Freq_ID for the Nth chunk plus 1? If so, does the first chunk have a
Freq_ID of 0, or 1, or some other value?
>
Yes, Freq_ID is a sequence number for the PPP chunks. The first chunk has a
Freq_ID of 0 and the Freq_ID of the next chunk will be incremented.
> The last chunk of a given PPP packet has a Flag value of 1; the others have a
Flag value of 0.
>
That is correct. The Flag is set to 1 if this chunk is the last chunk of the PPP
packet.
Kind regards,
Christoph Schemmel
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark Dissector
I just want to ask if you´ve already assigned a DLT value for the dissector? Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark
Guy Harris alum.mit.edu> writes:
>
> Not yet - I've been somewhat busy the past week and a half, and I have to
condense all the e-mail on this thread
> into a complete and precise description of the data format, to put into the
pcap/bpf.h and pcap-common.c
> files. If somebody else were to do so, that would probably speed the process
up significantly-
>
Hello Guy,
this is the detailed description of the data format.
LINKTYPE_MUX27010
Packet structure:
1 23 4
Header_Size | Msg_ID | Freg_ID | Start_Pos | ...
(1 Octet) |(2 Octets) | (2 Octets) | (1 Octet) | ...
5 6 7
... End_pos | Flag | Direction | ...
... (1 Octet) | (1 Octet)| (1 Octet) | ...
89 10 11
... Flag_Mux | Address | Control | Length | ...
... (1 Octet) | (1 Octet) | (1 Octet) | (1 or 2 Octets) | ...
1213 14
... Information |FCS| Flag_Mux
... (n Octets) | (1 Octet) | (1 Octet)
Description:
Parts of the packets (Octets 8 - 14) of this link type frames are based on the
standard 3G TS 27.010, but they are slight deviations to meet the actual
implementation of Cinterion and Siemens modules, e.g. no I frame support, but an
additional UIH_E frame.
Besides this the original MUX_Frame (Octets 8 - 14) is extended by some extra
fields for PPP chunks and direction indication (Octets 1-7).
Description for Octets 1-7:
If there are PPP chunks in the Mux_Frame Information_Field (12) they will be
indicated by the {Msg_ID (2), Freg_ID (3), Start_Pos (4), End_Pos (5), Flag
(6)} quintuplets, there will be one quintuplet for every chunk.
Header_Size (1) and Direction (7) are always present. Msg_ID (2), Freg_ID (3),
Start_Pos (4), End_Pos (5) and Flag (6) are optional and not always present.
The Header_Size field indicates whether the octects 2-6 are present or not and
how often they are present: If a frame contains N PPP chunks, the Header_Size
field has the value 7N, otherwise the frame is invalid.
Start_Pos is the 1-origin index (from the beginning of MUX_Frame, Flag_Mux (8))
of the first byte of the chunk, and End_Pos is the 1-origin index (from the
beginning of MUX_Frame, Flag_Mux (8)) of the last byte of the chunk.
All the chunks of a given PPP packet have the same Msg_ID (2) value. Freq_ID (3)
is a sequence number for the PPP chunks. The first chunk has a Freq_ID of 0 and
the Freq_ID of the next chunk will be incremented.
The last chunk of a given PPP packet has a Flag (6) value of 1; the others have
a Flag value of 0.
The Direction field (7) indicates the direction of the Mux frame: "0" means from
GSM Modem to the Host; "1" means from Host to GSM Modem.
Description for Octets 8-14:
The Mux_Frames are based on the standard 27.010, but they are deviations.
The multiplexer protocol doesn´t distinguish between Basic and Advanced Option
and every packet begins with the 0xF9 flag.
The protocol for this Mux_Frames implements the Basic Option with the additional
feature of the Error Recovery Mode, which is a subset of the GSM 07.10 Advanced
Option. The control type of the UIH_E frame is coded as I frame, so they could
be a collision with TS 27.010.
A MUX27010 MUX_Frame (Octets 8 - 14) starts with a MUX_Frame header (which is a
TS 27.010-like header), followed by zero or more bytes of data.
It is possible that a valid Mux_frame - with PPP_frames as payload - has parts
that don´t correspond to a PPP packet described by Start_Pos (4) and End_Pos
(5).
These parts (AT commands or responses) are called "other data" and will be
uninterpreted and displayed as raw text in the Wireshark subtree. So the payload
can be a mixture of chunks of uninterpreted data and PPP chunks.
Kind regards,
Christoph Schemmel-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Request for new DLT value for Wireshark
Guy Harris alum.mit.edu> writes: > > OK, I've assigned 236 as LINKTYPE_MUX27010 and DLT_MUX27010. > Thank you very much! Kind regards, Christoph Schemmel - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
