ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 12845] First start with non-empty extcap folder after inst

Date: Fri, 09 Sep 2016 06:42:14 +0000

Comment # 4 on bug 12845 from
(In reply to Pascal Quantin from comment #2)
> Is it solely happening with USBPcapCMD.exe, or does your extcaptest.exe
> alone program also trigger the issue?

It is happening solely with USBPcapCMD.exe, but you have to know that my
extcaptest.exe does not actually capture, it just logs the command line
parameters it receives into a file (because I didn't know the Process
Explorer), and responds to --extcap-interfaces, --extcap-config, and
--extcap-dlts, which was the necessary minimum to satisfy dumpcap's initial
queries.

The calls to extcaptest.exe at Wireshark startup look as follows:

--extcap-interfaces 
--extcap-config --extcap-interface \\.\EoE2isdn1 
--extcap-config --extcap-interface \\.\EoE2isdn2 
--extcap-interfaces 
--extcap-dlts --extcap-interface \\.\EoE2isdn1 
--extcap-dlts --extcap-interface \\.\EoE2isdn2 
--extcap-config --extcap-interface \\.\EoE2isdn1 
--extcap-config --extcap-interface \\.\EoE2isdn2 

The responses configured are:

  if ($value eq "^--extcap-interfaces")  {
    print "interface {value=\\\\.\\EoE2isdn1}{display=EoE2isdn D-channel 1}\n";
    print "interface {value=\\\\.\\EoE2isdn2}{display=EoE2isdn D-channel 2}\n";
  }

  if ($value =~ /^--extcap-config/ ) {
    print "arg {number=0}{call=--snaplen}{display=Snapshot
length}{tooltip=Snapshot
length}{type=integer}{range=0,65535}{default=65535}\n";
    print "arg {number=99}{call=--filename}{display=Destination for audio
files}{tooltip=Select target directory}{type=fileselect}\n";
  }

  if ($value =~ /^--extcap-dlts/ ) {
    print "dlt {number=249}{name=USBPCAP}{display=USBPcap}\n";
  }

> As we package the same USBPcap
> version between 2.0.X and 2.2, I presume this should not be the culprit.

Well, with 2.0.5, the last digit of USBPcap package ID was 3, now with 2.2.0 it
is 5, I have no idea what the actual difference is but definitely it is not
"the same USBPcap version". BTW, who maintains USBPcap as Tomasz seems to be
busy dealing with other things? I mean, there is the CPU resources issue I've
filed at github which makes live capture with USBPcap a bit adrenaline even
without the currently discovered issues, and it still exists even in the ....5
version.

> I never faced such issue on my side :(

How can I help further? Will it help you if I install the Process Manager and
check what is the command line of the zombie USBPcapCMD.exe which stays running
after Wireshark freezes?


You are receiving this mail because:
  • You are watching all bug changes.