[tcpdump-workers] tcpdump and wireshark
Hello. I'm interesting in info extraction from pcap dumps. Recently I did some test dump of downloaded picture with tcpdump and wrote it to file 'dump.pcap'. Test zero: I have started capture on 192.168.0.1 host and did http request of image to 192.168.0.2 Nothing else dropped to dump except arp requests etc. Test one: I've opened dump with wireshark. Found stream, filtered it out and saved raw data to file 'dump.hex' Deleted HTTP request till \xff byte before JFIF header and got image. Test two: I've processed dump thru tcpdump in command-line manner $> tcpdump -nn -r dump.pcap src host 192.168.0.2 and src port 80 and dst host 192.168.0.1 and dst port 50713 -w dump.hex Deleted HTTP request till \xff byte before JFIF header and got wrong image. So, there I've got in trouble. What I'm doing wrong with tcpdump? Thank You. Dmitry. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump and wireshark
By ´raw´ data I mean collected binary data from the payloads. Wireshark does correctly restore binary stream from payloads. I don´t know how to do this via tcpdump (if it possible off course) I did extract HTTP reply as binary stream. Divided it with hexedit to text data (header) and binary data (image object). Dmitry. On 9/16/08, Guy Harris <[EMAIL PROTECTED]> wrote: > > On Sep 15, 2008, at 2:05 PM, Dmitry wrote: > >> Test one: >> I've opened dump with wireshark. >> Found stream, filtered it out and saved raw data to file 'dump.hex' > > What do you mean by "raw data"? Do you mean raw *binary* data, or raw > data as a hex dump? > > And did you save the raw contents of the packets, or did you extract > the payload of the HTTP 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] tcpdump and wireshark
Hm, did´nt help. Dmitry. On 9/16/08, Arien Vijn <[EMAIL PROTECTED]> wrote: > > On 15 sep 2008, at 23:05, Dmitry wrote: > >> Hello. >> I'm interesting in info extraction from pcap dumps. >> Recently I did some test dump of downloaded picture with tcpdump and >> wrote >> it to file 'dump.pcap'. >> >> Test zero: >> I have started capture on 192.168.0.1 host and did http request of >> image to >> 192.168.0.2 >> Nothing else dropped to dump except arp requests etc. >> >> Test one: >> I've opened dump with wireshark. >> Found stream, filtered it out and saved raw data to file 'dump.hex' >> Deleted HTTP request till \xff byte before JFIF header and got image. >> >> Test two: >> I've processed dump thru tcpdump in command-line manner >> $> tcpdump -nn -r dump.pcap src host 192.168.0.2 and src port 80 and >> dst >> host 192.168.0.1 and dst port 50713 -w dump.hex >> Deleted HTTP request till \xff byte before JFIF header and got wrong >> image. >> >> So, there I've got in trouble. What I'm doing wrong with tcpdump? > > Snap length I guess. Tcpdump's default is 68 bytes. Try the parameter: > "-s 0" to capture the whole packet. > > I believe that tshark captures the entire packet by default. > > -- Arien > > - > 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] tcpdump and wireshark
Thank you. I´ll try. I think, I found what´s going on. I´ve read manual more accurately and found, that -w key writes WHOLE packets, NOT payloads. And now my question is: can tcpdump extract payloads from packets, or it just extracting headers? Dmitry. > You might want to look at tcpflow: > http://www.circlemud.org/~jelson/software/tcpflow/<http://www.circlemud.org/%7Ejelson/software/tcpflow/> > > Regards, > > Marco. > > - > 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] tcpdump and wireshark
Yeah! You´re right! Dumping packets via tcpdump to file, I can choose packet and cut out payload starting from 0x0042 Therefore It could be done via dd utility and some scripting avoiding libpcap. Via tcpflow I can dump sessions. That´s more convenient. Thanks in advance! It would be better to make tcpdump available dump payloads. Dmitry On Mon, Sep 22, 2008 at 2:12 PM, <[EMAIL PROTECTED]> wrote: > > > And now my question is: > > can tcpdump extract payloads from packets, or it just extracting headers? > > No, tcpdump by itself can't. But that's what tcpflow does. > >Regards, > > Marco. > - > 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] DLT_ reserve request for IPMI trace captures
Hello, all, Can I expect any reply (better positive :)) regarding my question? If more details are required in order to get progress on the request, I can submit them. Looking forward for any comments. Regards, Dmitry 06.05.2014 14:05, Dmitry пишет: Hello, PCAP library maintainers, Please, reserve a DLT_ number for IPMI message trace captures used by the Pigeon Point Systems ipmb_traced utility. The ipmb_traced utility is capable to capture IPMI traces from several IPMI channels simultaneously. The traced IPMI channels may have different messaging protocols. The captured data includes meta-data which describes each trace packet: which channel the packet is from, its direction, protocol format, and other characteristics. The capture data format differs from formats of already defined DLT_ types (199 and 209), thus, the new DLT_ value is needed. My suggestion is to name the new value as DLT_IPMI_TRACE. With regards, Dmitry Bazhenov ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT_ reserve request for IPMI trace captures
Hello, Guy, I guess there was some race between my authorization in the tcpdump-workers mailing list and my first mail. Here is the meta-data structure: Offset Size Description --- 01 Trace Data Block Type [7:6] Reserved [5:4] Packet Type 0 – IPMI Trace Packet Data. 1 - Channel State Change Notification. 2 - Embedded ASCII message. 3 - Reserved. [3:0] – IPMI Channel Number being traced. --- 1 4Timestamp (seconds part), little endian --- 52Timestamp (milliseconds part in the range 0 to 999), little endian --- 71Trace Data Type(IPMI Channel Protocol Type) See IPMI 2.0 Table 6-2, “Channel Protocol Type Numbers”. The following values are defined in the IPMI 2.0 specification: 00h - n/a 01h - IPMB-1.0 02h - ICMB-1.0 03h - reserved 04h - IPMI-SMBus 05h - KCS 06h - SMIC 07h - BT-10 08h - BT-15 09h - TMode 1Ch-1Fh – OEM Protocol 1 through 4 All other - reserved --- 82Additional Protocol-specific data, little endian Additional data. Depends on the IPMI Channel Protocol Type for this packet. For protocol = IPMB-1.0 Byte 1 [7] - Direction 0 – From IPM Controller to target device. 1 – From target device to IPM Controller. [6] – Redundant channel indicator. When IPMI Channel does not support redundancy, 0 must be returned. 0 – First channel. (IPMB-A in the case of redundant IPMB-0) 1 – Second channel. (IPMB-B in the case of redundant IPMB-0) [5:0] – Radial IPMB Link Number (0 if IPMB is bussed), see below. Byte 2 [7:0] – Reserved. NOTE: For the IPMB-1.0 protocol, the connection topology can be either radial or bused. In the case of a radial topology, each IPMB device (or possibly group of IPMB devices) is connected with a radial hub via a separate link. If an IPMB radial hub is traced, the number of the link over which the packet is sent or received is included in byte 1 of the additional data. For Host-Interface (KCS, SMIC, BT-10, BT15) Byte 1 [7] - Direction 0 – From IPM Controller to host. 1 – From host to IPM Controller. [6:0] – Reserved. Byte 2 [7:0] – Reserved. --- 10 1Size of subpacket data. --- 11 NData bytes. --- Regards, Dmitry 09.05.2014 1:47, Guy Harris пишет: On May 8, 2014, at 9:07 AM, Dmitry wrote: Can I expect any reply (better positive :)) regarding my question? You can't expect a reply until people see your message. :-) Your original message never arrived in my mailbox, and may never have made it to the list (moderation?), so I didn't see anything until today. If more details are required in order to get progress on the request, I can submit them. Looking forward for any comments. Regards, Dmitry 06.05.2014 14:05, Dmitry пишет: Hello, PCAP library maintainers, Please, reserve a DLT_ number for IPMI message trace captures used by the Pigeon Point Systems ipmb_traced utility. The ipmb_traced utility is capable to capture IPMI traces from several IPMI channels simultaneously. The traced IPMI channels may have different messaging protocols. The captured data includes meta-data which describes each trace packet: which channel the packet is from, its direction, protocol format, and other characteristics. Please give a detailed description of the meta-data format, with the byte order of multi-byte integral-valued fields specified. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT_ reserve request for IPMI trace captures
Hello, Guy, Did you get the mail with the format details? I'm looking forward to your comments. Regards, Dmitry 09.05.2014 17:11, Dmitry пишет: Hello, Guy, I guess there was some race between my authorization in the tcpdump-workers mailing list and my first mail. Here is the meta-data structure: Offset Size Description --- 01 Trace Data Block Type [7:6] Reserved [5:4] Packet Type 0 – IPMI Trace Packet Data. 1 - Channel State Change Notification. 2 - Embedded ASCII message. 3 - Reserved. [3:0] – IPMI Channel Number being traced. --- 1 4Timestamp (seconds part), little endian --- 52Timestamp (milliseconds part in the range 0 to 999), little endian --- 71Trace Data Type(IPMI Channel Protocol Type) See IPMI 2.0 Table 6-2, “Channel Protocol Type Numbers”. The following values are defined in the IPMI 2.0 specification: 00h - n/a 01h - IPMB-1.0 02h - ICMB-1.0 03h - reserved 04h - IPMI-SMBus 05h - KCS 06h - SMIC 07h - BT-10 08h - BT-15 09h - TMode 1Ch-1Fh – OEM Protocol 1 through 4 All other - reserved --- 82Additional Protocol-specific data, little endian Additional data. Depends on the IPMI Channel Protocol Type for this packet. For protocol = IPMB-1.0 Byte 1 [7] - Direction 0 – From IPM Controller to target device. 1 – From target device to IPM Controller. [6] – Redundant channel indicator. When IPMI Channel does not support redundancy, 0 must be returned. 0 – First channel. (IPMB-A in the case of redundant IPMB-0) 1 – Second channel. (IPMB-B in the case of redundant IPMB-0) [5:0] – Radial IPMB Link Number (0 if IPMB is bussed), see below. Byte 2 [7:0] – Reserved. NOTE: For the IPMB-1.0 protocol, the connection topology can be either radial or bused. In the case of a radial topology, each IPMB device (or possibly group of IPMB devices) is connected with a radial hub via a separate link. If an IPMB radial hub is traced, the number of the link over which the packet is sent or received is included in byte 1 of the additional data. For Host-Interface (KCS, SMIC, BT-10, BT15) Byte 1 [7] - Direction 0 – From IPM Controller to host. 1 – From host to IPM Controller. [6:0] – Reserved. Byte 2 [7:0] – Reserved. --- 10 1Size of subpacket data. --- 11 NData bytes. --- Regards, Dmitry 09.05.2014 1:47, Guy Harris пишет: On May 8, 2014, at 9:07 AM, Dmitry wrote: Can I expect any reply (better positive :)) regarding my question? You can't expect a reply until people see your message. :-) Your original message never arrived in my mailbox, and may never have made it to the list (moderation?), so I didn't see anything until today. If more details are required in order to get progress on the request, I can submit them. Looking forward for any comments. Regards, Dmitry 06.05.2014 14:05, Dmitry пишет: Hello, PCAP library maintainers, Please, reserve a DLT_ number for IPMI message trace captures used by the Pigeon Point Systems ipmb_traced utility. The ipmb_traced utility is capable to capture IPMI traces from several IPMI channels simultaneously. The traced IPMI channels may have different messaging protocols. The captured data includes meta-data which describes each trace packet: which channel the packet is from, its direction, protocol format, and other characteristics. Please give a detailed description of the meta-data format, with the byte order of multi-byte integral-valued fields specified. ___ tcpdump-workers mailing list
Re: [tcpdump-workers] DLT_ reserve request for IPMI trace captures
Hello, Guy,
Please, see below
08.06.2014 2:17, Guy Harris пишет:
OK, so all we would need to say on http://www.tcpdump.org/linktypes.html would
be:
LINKTYPE_whatever {number}DLT_whateverTrace data blocks, as
specified by Table 3-20 "Trace Data Block Format" in the PICMG HPM.2
specification
with "PICMG HPM.2 specification" linking to
http://www.picmg.org/v2internal/specifications2.cfm?thetype=One&thebusid=12 (that being
the closest thing we can provide to a link to the spec)?
Correct.
And a trace data block begins with
01 Trace Data Block Type
[7:6] Reserved
[5:4] Packet Type
0 – IPMI Trace Packet Data.
1 - Channel State Change Notification.
2 - Embedded ASCII message.
3 - Reserved.
[3:0] – IPMI Channel Number being traced.
and the HPM.2 spec describes the format of IPMI Trace Packet Data (either
directly or by referring to IPMI specs), the format of Channel State Change
Notifications, and the format of embedded ASCII messages?
Correct?
Correct.
Also, are the time stamps in pcap records or pcap-ng packet blocks significant,
given that the trace blocks contain their own time stamps?
They would not be significant, if Wireshark did not use them for
displaying packet times. But, since Wireshark does use them, then for
the sake of usability they are in fact significant and should match the
time stamps in the captured trace data blocks.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] DLT_ reserve request for IPMI trace captures
Hello, Guy, Please, see below. 09.06.2014 13:43, Guy Harris пишет: OK, I've assigned 260 to LINKTYPE_IPMI_HPM_2/DLT_IPMI_HPM_2, with a description of: IPMI trace packets, as specified by Table 3-20 "Trace Data Block Format" in the PICMG HPM.2 specification. with the link done as specified. Thanks. Also, are the time stamps in pcap records or pcap-ng packet blocks significant, given that the trace blocks contain their own time stamps? They would not be significant, if Wireshark did not use them for displaying packet times. But, since Wireshark does use them, As will other programs that read pcap or pcap-ng files and don't treat LINKTYPE_IPMI_HPM_2 specially (one reason for this registry is to allow other programs to process whatever pcap/pcap-ng link-layer header types the developers choose; the goal is to *avoid* tying link-layer header types to tcpdump or Wireshark or any other program - it should be possible for people to write code to read or write packets of any given link-layer header type without ever having to see any tcpdump/Wireshark/etc. code that reads or writes them). Since the proposed capture format is generated by a proxy agent which transforms the captured data from the UDP-based connection, time stamps in pcap records/pcap-ng packet blocks may be interpreted as times of receiving of the encapsulated trace data blocks by the proxy from the capturing device, while the trace data block contain time stamps for the captured trace messages. The only utility which I know generates data in the proposed capture format, makes the timestamps in pcap records equal to the stamps in the trace data blocks which is convenient when browsing the captured data in Wireshark. However, in general, this is not required. In that sense, the proposed capture format is not tied to any analyzing program. Regards, Dmitry ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] mmap-ed tcpdump and gigabit ethernet
Greetings, all! I would like to have an efficient capturing solution for a gigabit network. It seems as if Phil Wood's libpcap should do the work. However, I am not sure as for its support for the jumbo frames. When in MMAP mode, this version of tcpdump doesn't seem to cope with -s 0 or -s N for N >> 4000 (terminating with Error: setsockopt(PACKET_RX_RING): Invalid argument \n tcpdump: malloc: Illegal seek), whereas in the NORMAL mode I can see frames as large as 9000 bytes (and more). Anyone has had this problem (and solved it)? Thanks! -- Sailing: The fine art of getting wet and becoming ill while slowly going nowhere at great expense. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] mmap-ed tcpdump and gigabit ethernet
Sorry, forgot to specify that this is a Linux with kernel 2.6.18-1.2798, pcap libpcap-0.9.20060417 by Phil Wood and tcpdump 3.9.3 by the same. -- Sailing: The fine art of getting wet and becoming ill while slowly going nowhere at great expense. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dmitry Rubinstein Sent: Monday, January 08, 2007 11:56 AM To: tcpdump-workers@lists.tcpdump.org Subject: [tcpdump-workers] mmap-ed tcpdump and gigabit ethernet Greetings, all! I would like to have an efficient capturing solution for a gigabit network. It seems as if Phil Wood's libpcap should do the work. However, I am not sure as for its support for the jumbo frames. When in MMAP mode, this version of tcpdump doesn't seem to cope with -s 0 or -s N for N >> 4000 (terminating with Error: setsockopt(PACKET_RX_RING): Invalid argument \n tcpdump: malloc: Illegal seek), whereas in the NORMAL mode I can see frames as large as 9000 bytes (and more). Anyone has had this problem (and solved it)? Thanks! -- Sailing: The fine art of getting wet and becoming ill while slowly going nowhere at great expense. - 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.
[tcpdump-workers] Filter complexity and performance
Greetings, everyone! We are trying to capture stuff using a relatively simple filter (on Linux, using Phil Wood's PCAP with ssldump on top of it). What we want is basically to capture the traffic to and from a specific port of a specific host (say, 10.0.0.1:80). So far we did it using the filter 'host 10.0.0.1 and port 80', but obviously that means we also see traffic originating from 10.0.0.1 to port 80 of other hosts. The simple way to prevent that would be to use a bit more elaborate filter: '(dst host 10.0.0.1 and dst port 80) or (src host 10.0.0.1 and src port 80)'. This means the filter has grown two fold in the number of clauses. What will be the implications upon the performance of the filtering code? Will we be able to capture twice as few packets (hopefully not)? I was hoping to kinda avoid the need to do this test if anyone has already did some sort of evaluation... Thanks! -- Sailing: The fine art of getting wet and becoming ill while slowly going nowhere at great expense. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Capture/decode SSL
I would also add that there exists a tool called ssldump (also operating on top of libpcap) that is indeed able (under certain conditions) to capture and decode SSL traffic. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 8:08 PM To: tcpdump-workers@lists.tcpdump.org Subject: Re: [tcpdump-workers] Capture/decode SSL Excellent information. Thanks, Guy! tl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris Sent: Tuesday, January 23, 2007 12:59 PM To: tcpdump-workers@lists.tcpdump.org Subject: Re: [tcpdump-workers] Capture/decode SSL [EMAIL PROTECTED] wrote: > I need to capture and decode SSL traffic. Does tcpdump support this? Tcpdump supports capturing *all* network traffic; if it captures and saves packets to a file, the packet contents are just a big bucket of bytes. Note that its default "snapshot length" is 68 bytes in versions built without IPv6 support and 96 bytes in version built with IPv6 support, so, by default, you will only get the first 68 or 96 bytes of each packet; to override that, use "-s 0" in modern versions of tcpdump (and "-s 65535" in older versions), which will give you up to 65535 bytes of each link-layer packet. It doesn't support decoding SSL, however. Recent versions of Wireshark can capture and decode SSL, complete with decryption in at least some cases, and can also read captures from tcpdump (its native capture file format is the same as that of tcpdump), as well as captures from a number of other network analyzers. - 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. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] tcpdump bin
Hello! Can I offer binary version of tcpdump for my on needs? To trace traffic on my own notebook? Thank You. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
