Hi, When using Wireshark with remote packet capture against remote interface running rpcapd (and capture is done over UDP), I get sometimes packet loss in the network due to network congestion. Although these lost packets are indicated in the RPCAP “frame number” (i.e. received RPCAP captured packets frame numbers are not consecutive), it seems that Wireshark is renumbering the received RPCAP UDP captured packets and display the packet numbers as consecutive. To my understanding the displayed numbers should be taken from the RPCAP “frame number” so the lost packets will be shown as “missing”. Is there some configuration to change that ? Thanks, Guy asked 21 Apr '16, 03:31  Guyg edited 21 Apr '16, 03:50 |
One Answer:
Wireshark always numbers packets consecutively, as seen by the dumpcap program (which is part of Wireshark, and what Wireshark runs to do capturing). There's no provision for having the captured frames numbered differently. If your remote capture is being done by telling Wireshark to capture on a remote machine, WinPcap is not passing the packet number from the RPCAP messages to Wireshark, so Wireshark has no idea what the packet numbers were when captured on the remote machine. If your remote capture is being done by another program, and Wireshark is capturing on the network over which that program and the machine on which the capture is being done are communicating, with Wireshark dissecting the RPCAP protocol and the packets carried over it, what you could do is edit the list of displayed columns, remove the "frame number" column, and add a custom column displaying the "rpcap.number" field, and call that column "Num" or "Number". answered 21 Apr '16, 14:04  Guy Harris ♦♦ edited 22 Apr '16, 10:31 showing 5 of 13 show 8 more comments |
Hi Guy,
Thanks for the answer ! Re “Wireshark always numbers packets consecutively, as captured.”:
I agree, but, I think in this case the RPCAP “frame number” represent the actual order on the port, as we are talking about “remote interface” ?
Regarding your proposal: I didn’t manage to add a "frame number" as a column when I'm capturing from remote interface as it seems Wireshark removes the RPCAP encapsulation before displaying the packets (I did managed doing that when capturing from the local port and applying display filter of “rpcap and udp” but then the packets are shown with their encapsulation which is a pity when one have the ability of showing the traffic exactly as on remote port).
Thanks again,
Guy
I've updated the question to 1) give more details as to what "as captured" means and 2) talk about two different ways in which an RPCAP capture can be handled by Wireshark.
Hi Guy,
Thanks for the clarification ! I think the RPCAP "frame number" delivers a very important info that adds to the reliability of the remote capture data. As it is already delivered together with the captured packet, it'll be very beneficial if it will be shown (together with the regular number) in Wireshark's display. Is there a way to suggest that WinPcap will be modified to pass the RPCAP "frame number" to Wireshark ?
Thanks, Guy
WinPcap's API will probably track libpcap's API (especially once the new remote capture support gets into libpcap), so the right place to ask would be on the [email protected] mailing list or the libpcap issues list on GitHub.
However, are the frame numbers interesting by themselves, or is what's interesting an indication of the points at which packets were dropped and a number of dropped packets? Handling the drop indications would require support in pcapng; there's already an "epb_dropcount" option in the Enhanced Packet Block, and an "epb_remotedropcount" option, or something such as that, could record drops in remote captures due to packets not being received by libpcap/WinPcap.
Hi Guy, As far as I know, RPCAP is not supported on libpcap. Can you elaborate on the "new remote capture support gets into libpcap" ?
The frame numbers are of interest as someone who uses remote capture to debug a network problem, need to know if the information he reviews is indeed the actual packets at the remote port or some info is missing due to (additional other) network problem.
I just realized that as the RPCAP frame numbers are not passed by WinPcap to Wireshark, this is probably the case with the RPCAP timestamps that are not passed to Wireshark as well ? :-(
Interesting to hear about the pcapng RFC. Will libpcap support it as well as Winpcap ?
Thanks, Guy
RPCAP support can be added to libpcap, and some have added it. However, it doesn't fit well with the new
pcap_create()andpcap_activate()APIs, and may not be general enough to handle other forms of remote capture, so I have a work in progress to add new APIs to go along withpcap_create()andpcap_activate()to support multiple remote capture mechanisms.If the packets are delivered to the program using libpcap/WinPcap in order by frame number (which the RPCAP client should do), what information would be unavailable to the person doing the remote capture if every packet for which some previous packets had been lost over the network included a count of lost packets, rather than having each packet have a frame number (from which the count of lost packets can be calculated), and the lost packet counts were displayed?
Hi, Not sure I follow you, but as I see it, knowing the amount of lost packets may be insufficient. Sometimes there is a need to debug specific session running specific protocol. For example, when a handshake between client and server is malfunctioning, there is a need to analyze the protocol packet by packet (e.g. when there is a request and no response). In such debug, it'll be most confusing to see some of the handshake missing while not knowing if the missing packet is a real problem occurring at the remote port or just additional problem due to congestion in the path between remote port and Wireshark.
No. The libpcap/WinPcap APIs don't pass any frame numbers to its callers, so there's no provision to pass a frame number from the RPCAP packet. Those APIs do pass a time stamp, and the only time stamp that makes sense for them to pass is the one from the RPCAP packet, so that's what they pass.
It's not just the number of lost packets, it's the point at which they're lost - Wireshark could, for example, display in the packet list pane, for example, in addition to packets, "N packets dropped" indications (and should do so for all packets dropped, not just packets dropped due to remotely-captured packets not being received - currently, few if any packet capture mechanisms supply packet drop counts along with packets, but pcapng supports that, and I'd like to get that ability into the {Linux, BPF, etc.} packet capture mechanisms.
libpcap already has limited support for it; the current libpcap APIs can't handle more than one link-layer header type, snapshot length, or section byte order in a capture, but any program using sufficiently recent versions of libpcap can read pcapng files in which all the network interfaces have the same link-layer header type and snapshot length and all the sections have the same byte order.
Current WinPcap releases, however, are based on an older version of libpcap that didn't support pcapng, so it doesn't currently support reading pcapng files.
Future versions of libpcap will offer an alternative API that can read arbitrary pcapng files (and that will also read pcap files, with the application not needing to know or care what type of file it is), as well as offering the current APIs; versions of WinPcap or NPcap based on those future versions will have the same capabilities.
Interesting. I hope to go over the RFC in more details later. One thing I think will be of value is to add indication of the packet direction (ingress/egress). As you suggested, I will post a request in libpcap issues list on GitHub for RPCAP support in general and passing on RPCAP frame number specifically. Many thanks ! Guy
Presumably meaning "display, in Wireshark, the direction indication, for file formats that support it, including pcapng"; pcapng's Enhanced Packet Block (and deprecated Packet Block) have an epb_flags option (or pb_flags for the Packet Block) that includes an optional indication of whether the packet is incoming or outgoing.
This applies when capturing on an interface that's an active network device, such as an Ethernet or Wi-Fi adapter. If you're doing passive tapping on a wire, all packets are incoming; if this is passively capturing on a connection to, for example, an ISDN or ATM network, the "user to network" or "network to user" direction would be provided in a pseudo-header at the beginning of the packet data.