Re: [tcpdump-workers] "snaplen of 0" when reading pcap-ng data
On Apr 25, 2012, at 5:12 PM, Andrew Daviel wrote:
> I just built libpcap-1.2.1 and tcpdump-4.2.1 on Centos 6.2.
>
> If I read a pcap-ng capture file from the Hone project, or one written by
> Wireshark 1.7.2 on XP with the default filter, I get a message "snaplen of 0
> rejects all packets" and tcpdump displays no packets.
>
> If I capture data with Wireshark with a maximum packet length of 65535, or
> shorter, and save it as pcapng, I can read it in tcpdump.
>
> I can't capture data from Hone, even with -s (tcpdump -r /dev/hone -s 500)
> and I can't build a Wireshark that supports pcapng on RHEL 6 (glib in latest
> release is too old)
>
> Is there a way around this problem ?
There are multiple problems here:
1) the pcap-ng spec:
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html#sectionidb
neither says that the snapshot length field in an Interface
Description Block must be non-zero nor what should be done if you don't have a
snapshot length ("TODO: Is there a need to signal "no limit"?")
2) honeevent.c in Hone:
https://github.com/HoneProject/Linux-Sensor
is defaulting to a snapshot length of 0, meaning "no snapshot
length", and writing that out in the Interface Description Block;
3) Wireshark 1.7.2 appears to be writing out capture files with a
snapshot length of 0 in the Interface Description Block, at least with the
default snapshot length setting (the filter is irrelevant here);
4) libpcap is not accepting 0 as meaning "no snapshot length" in
several places, including the BPF compiler (where it should presumably make
2^32-1 be the return value of the RET instruction - 0 in the RET instruction
means "reject the packet", hence the warning from tcpdump) *AND* in the
savefile reading code (which allocates a buffer big enough for the specified
snapshot length; it'd need to pick some appropriate size initially, and grow
the buffer if a larger packet size is seen).
The right long-term fix is probably to:
have libpcap treat the snapshot length as a hint, and grow the buffer
as necessary - this will also be necessary when APIs to fully support pcap-NG
are added, as there might be different Interface Description Blocks in a file,
with different snapshot lengths, and an IDB could appear *after* packets are
seen (obviously not an IDB for those packets, but for an additional interface);
have the specs for both pcap and pcap-ng say that the snapshot length
can, in theory, be zero, but that this isn't recommended, as older versions of
libpcap will not be able to handle it;
fix Wireshark to make sure it supplies a non-zero value in the
Interface Description Block for all interfaces.
A short-term workaround might be to run the file through Wireshark's editcap
utility, with "-s 65535"; that might forcibly set the snapshot length in the
IDBs to 65535, in which case libpcap (1.1.0 or later, as that's when pcap-ng
support was added) should be able to read them. (You'll lose the Hone-specific
pcap-ng extensions, as Wireshark's Wiretap capture-file-reading library
currently doesn't know about them and currently doesn't offer APIs that let
applications pass unknown pcap-ng blocks through to an output file, but tcpdump
would ignore them anyway, as libpcap also doesn't know about them.)-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pipeline buffering
On Mar 10, 2012, at 12:01 PM, jedge wrote: > I suppose if you don't HAVE_PCAP_DUMP_FLUSH If the libpcap with which tcpdump is built is a version released at the same time, or after, the time that version of tcpdump is released, it'll have pcap_dump_flush(). A version of tcpdump with -U support in the source will lack -U support only if linked with an older version of libpcap, e.g. if you have a system with an older version of libpcap (which will probably also include an older version of tcpdump), and you download a newer version of the tcpdump source and build it with the libpcap you have on your system. > maybe for morons like me we can add a reference to -U in -w: How about −w Write the raw packets to file rather than parsing and printing them out. They can later be printed with the −r option. Stan‐ dard output is used if file is ‘‘‐’’. This output will be buffered if written to a file or pipe, so a program reading from the file or pipe may not see packets for an arbitrary amount of time after they are received. Use the −U flag to cause packets to be written as soon as they are received. See pcap‐savefile(5) for a description of the file format. I've checked that version into the trunk and the 4.2 branch. > and since -U is conditional upon -w then it can be reflected in the usage. Actually, it's not conditional upon -w; if you don't specify -w, -U means "flush the standard output after the information for each packet is printed" (which does a bit more buffering than -l - especially on Windows, where, apparently, "line buffering" means "no buffering", if I remember correctly). And, yes, the man page needs to be updated to reflect that. I'll do that.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap DLT request for virtio-scsi SCSI transport
On Mar 26, 2012, at 2:17 AM, Cong Meng wrote:
> I drafted some description. Should I make an HTML version?
Yes, matching the style of the other ones, once the issues that are raised are
resolved.
(Of course, for the diagrams, we just cheat and use .)
> LINKTYPE_VIRTIO_SCSI
>
> Packet structure
>
> +---+
> | Pack Type|
> | (4 Octets) |
> +---+
> | Tag |
> | (4 Octets) |
> +---+
> | Initiator|
> | (4 Octets) |
> +---+
> | Target |
> | (4 Octets) |
> +---+
> | Lun |
> | (4 Octets) |
> +---+
> | CDB Size |
> | (4 Octets) |
> +---+
> | Sense Size |
> | (4 Octets) |
> +---+
> | Header Size |
> | (4 Octets) |
> +---+
> | Data Size|
> | (4 Octets) |
> +---+
> | |
> | Header |
> | |
> +---+
> | |
> | Data |
> | |
> +---+
>
>
> Description
>
> Pack Type:
> REQ_CMD 0x000
> REQ_TMF 0x010
> REQ_ANQ 0x011
> REQ_ANS 0x012
>
> RESP_CMD0x100
> RESP_TMF0x110
> RESP_ANQ0x111
> RESP_ANS0x112
So what do the packet types mean? Are they:
REQ_CMD SCSI command
RESP_CMDSCSI command response
REQ_TMF task management function
RESP_TMFtask management function response
REQ_ANQ asynchronous notification query
RESP_ANQasynchronous notification query response
REQ_ANS asynchronous notification subscription
RESP_ANSasynchronous notification subscription response?
And do they all have the same contents, with the same fields filled in, or are
some fields not used for some packet types?
> Tag:
> The tag to match a response to corresponding request.
I.e., both requests and responses have tag values, and the tag values for a
given request and its response are the same?
> CDB Size:
> The maximal size of CDB.
>
> Sense Size:
> The maximal size of Sense data.
So is that the maximum size or the actual size? The description of a SCSI
command request is
struct virtio_scsi_req_cmd {
// Read−only
u8 lun[8];
u64 id;
u8 task_attr ;
u8 prio;
u8 crn;
charcdb [ cdb_size ] ;
chardataout [ ] ;
// Write−only part
u32 sense_len ;
u32 residual ;
u16 status_qualifier ;
u8 status ;
u8 response ;
u8 sense [ sense_size ];
chardatain [ ] ;
};
so would "CDB Size" be the same as cdb_size and "Sense Size" be the same as
sense_size?
> Header Size:
> The size of the header of a request/response.
>
> Data Size:
> The size of Data-Out or Data-In.
>
> Header:
> The request or response header.
> This header is described in Appendix H of the virtio specification:
> http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.4.pdf
Are the headers:
REQ_CMD, RESP_CMD struct virtio_scsi_req_cmd
REQ_TMF, RESP_TMF struct virtio_scsi_ctrl containing
struct virtio_scsi_ctrl_tmf
REQ_ANQ, RESP_ANQ struct virtio_scsi_ctrl containing
struct virtio_scsi_ctrl_an
REQ_ANS, RESP_ANS struct virtio_scsi_ctrl containing
struct virtio_scsi_ctrl_an
Or is the header for a REQ_xxx the "Read-only part" and for a RESP_XXX the
"Write-only part"?
And do the headers include the LUN, given that the packet structure also
includes a LUN - although the packet structure's LUN is 4 bytes rather than 8
bytes?
Do they include the type field in struct virtio_scsi_ctrl, given that the type
field seems to be VIRTIO_SCSI_T_TMF for REQ_TMF/RESP_TMF,
VIRTIO_SCSI_T_AN_QUERY for REQ_ANQ/RESP_ANQ, and VIRTIO_SCSI_T_AN_SUBSCRIBE for
REQ_ANS/RESP_ANS, so it's redundant?
> Data:
> Data-Out or Data-In block.
The request description above includes "dataout" and "datain" fields; are those
absent from the Header field and, instead, contained in the Data field?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
