This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Dumpcap access violation with remote capture

0

Hello everyone,

I've implemented a remote capture server based on the Remote Packet Capture Protocol v.0 (actually based on the communication supported by the RPCAP daemon from WinPcap) with some virtual interfaces which are specifically managed on the server.

The server can communicate with Wireshark and deliver a list of interfaces and start a capture with devices present in the list (no devices are currently delivering data, so the capture is empty). In fact, the capture with multiple interfaces can sometimes be successfully started. However, sometimes the dumpcap process activated by the capture delivers an "Access violation" message.

I'm currently using Wireshark 1.8.3, which is, as far as I know, from late 2011. I've also checked for the error message online and saw a notice related to an access violation in dumpcap from 2012. Do you know if there is a place in dumpcap where the access violation is likely to happen? One important fact is that the implemented server delivers devices with no addresses, as they are irrelevant inside the server. Is it possible that dumpcap accesses a null address structure in the device list and gets the access violation from there?

Thanks!

EDIT: The error seems to go away if I disable the option "Do not capture own RPCAP traffic" in "Edit Interface Settings"→"Remote Settings".

asked 23 Oct '13, 04:19

Matheus%20Priebe%20Bertram's gravatar image

Matheus Prie...
6335
accept rate: 100%

edited 23 Oct '13, 06:23

I've implemented a remote capture server based on the Remote Packet Capture Protocol v.0

what do you mean by 'implemented'? Did you write your own rpcap daemon or did you use an existing tool? If the later, please tell us:

  • your OS and version of the client (where dumpcap is running)
  • your OS and version of the server (where the rpcap daemon is running)
(28 Oct '13, 09:30) Kurt Knochner ♦

I wrote my own rpcap daemon based on the "standard" rpcap daemon from WinPcap in order to get the communication protocol right.

Client: Windows XP SP3. Server: openSUSE Linux 11.2.

I've debugged dumpcap and the problem seems to be around a call to pcap_dispatch. The access violation happens after the server has sent a start capture reply. As previously said, the failure does not happen if the option "Do not capture own RPCAP traffic" is turned off.

Thanks for the response.

(30 Oct '13, 03:17) Matheus Prie...

2 Answers:

0

The problem is solved now. After installing WinPcap 4.1.2 replacing WinPcap 4.0.2 (these modifications take place on the client, the server has used WinPcap 4.1.3 from the beginning) the client dumpcap does not crash anymore (at least statistically :-)). I'm not quite sure, however, about what exactly is the essential difference between both versions. That would require a thorough examination of both source codes.

answered 04 Nov '13, 02:15

Matheus%20Priebe%20Bertram's gravatar image

Matheus Prie...
6335
accept rate: 100%

0

I wrote my own rpcap daemon based on the "standard" rpcap daemon from WinPcap in order to get the communication protocol right.

Hm.. sounds like a bug in your version of the RPCAP protocol 'kills' dumpcap and/or Wireshark.

I've debugged dumpcap and the problem seems to be around a call to pcap_dispatch. The access violation happens after the server has sent a start capture reply.

hm.. if you provide the wrong data within your version of the RPCAP protocol (too much or not enough data), that could be a problem, although a memory access violation is pretty bad.

As previously said, the failure does not happen if the option "Do not capture own RPCAP traffic" is turned off.

that's odd and sounds like there might be a bug in the RPCAP dissector that is triggered by a failure in your version of the RPCAP protocol (the dissector kills Wireshark).

However: What I don't understand: You said, dumpcap gets killed not Wireshark, in which case it cannot be a dissector bug.

I guess, this is more a problem of (your) code debugging than anything that we can solve within the Wireshark community.

Regards
Kurt

answered 30 Oct '13, 07:16

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Hm.. sounds like a bug in your version of the RPCAP protocol 'kills' dumpcap and/or Wireshark.

That does not seem to be the case. I've traced the RPCAP communication between client and server with the RPCAP dissector and all packets are well-formed and correctly sent by the latter. I imagine the server could only kill the client's application if it had sent something incorrect, which is not the case.

hm.. if you provide the wrong data within your version of the RPCAP protocol (too much or not enough data), that could be a problem, although a memory access violation is pretty bad.

Not enough data, afaik, evokes a different problem on the client: it blocks until it receives at least the intended amount of data. This is also not the case, as the client accepts what it has received from the server and continues to run. Sending too much data seems not to be the case too, as the tracing done showed all packets sent from the server are well-formed. Furthermore, too much data should be treated by the client with a discard.

that's odd and sounds like there might be a bug in the RPCAP dissector that is triggered by a failure in your version of the RPCAP protocol (the dissector kills Wireshark).

Wireshak is not killed. Wireshark, when capturing, creates a new process which calls dumpcap. This new instance of dumpcap is killed by itself.

However: What I don't understand: You said, dumpcap gets killed not Wireshark, in which case it cannot be a dissector bug.

Correct. The RPCAP dissector seems to be working just fine.

I'll keep on checking and see what I can find. Thanks for the reply.

(31 Oct '13, 03:54) Matheus Prie...

What you say may or may not be the case. Hard to validate without access to the code of your RPCAP implementation.

BTW: Why did you write your own RPCAP daemon?

(31 Oct '13, 03:57) Kurt Knochner ♦

The standard RPCAP daemon lists all physical interfaces and is able to provide capture data which flows through them. What we are working with are, however, "virtual" interfaces. These are e.g. files or even processes on the server machine which generate their own PCAP data about some internal communication protocols we have. These data should then be sent over the network to the client.

(31 Oct '13, 04:16) Matheus Prie...

Ah, O.K. something totally different. Will your code be open source? If so, someone here might find some time to check the code and run some tests.

(31 Oct '13, 04:17) Kurt Knochner ♦

I'm not yet sure about that, but I would say it will unfortunately not be open source. It's something internal and I'm not sure there is an intention to publish it in the future.

(31 Oct '13, 04:26) Matheus Prie...

O.K. I guess then there is not much we can do for you ;-)

BTW: What happens if you run dumpcap manually (-i rpcap:// ...)? Does it crash as well?

(31 Oct '13, 04:46) Kurt Knochner ♦

Running dumpcap manually causes the same crash, yes.

I've run it both with "-i rpcap://..." and "-r -i rpcap://...". The first option works always for exactly one interface and sometimes when there is more than one interface. The second option runs always, for any number of interfaces. The same behavior is observed when running Wireshark normally.

Thanks again for the reply.

(31 Oct '13, 05:05) Matheus Prie...

I'm currently using Wireshark 1.8.3

can you please try a later release (1.10.x or 1.11.x)?

(31 Oct '13, 05:15) Kurt Knochner ♦

I've already tried with the latest release as well and get the same error...

(31 Oct '13, 05:56) Matheus Prie...

well, then have fun debugging your RPCAP code (or the code of dumpcap) ;-)

(31 Oct '13, 06:17) Kurt Knochner ♦

I've got some news: I was running Wireshark with WinPcap 4.0.2 the whole time. Now, I've installed WinPcap 4.1.2 (the Wireshark version still being 1.8.3) and the problem seems to be solved! :-) I'm going to check which are the differences between both releases to see if I can find where the problem could be. Thanks!

(31 Oct '13, 06:41) Matheus Prie...
showing 5 of 11 show 6 more comments