Error by extcap pipe - Исправление ошибок и поиск оптимальных решений проблем

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

Open

ziswiler opened this issue

Oct 28, 2020

· 3 comments

Comments

Trying to do remote capture via SSH with the following remote capture command (which BTW works if entered manually in an SSH shell):

/usr/bin/dumpcap -i enp0s31f6 -q -f 'not port 22' -w -

I get the following:

Error by extcap pipe: 
** (process:91): WARNING **: 14:37:12.828: Error creating connection.

** (process:91): WARNING **: 14:37:12.829: Connection error: Failed to connect: Network is unreachable

Maybe network access should at least be possible? How exactly is this supposed to work?

you should be able to run the flatpak with --share=network, e.g. flatpak run --share=network org.wireshark.Wireshark. You can persist that by using flatpak override.

@muelli why is that permission not added in the main manifest? It’s needed by Wireshark to function, it should be there.

@muelli why is that permission not added in the main manifest?

Because it’s a wide reaching and dangerous permission.

It’s needed by Wireshark to function, it should be there.

I appreciate that wireshark can make use of the network for some of its functionality. But my impression is that analysing pcap files is the biggest application of Wireshark and there, there is no need to make use of the network.

Источник

Open

Issue created Jan 18, 2022 by Glen Huang@hgl

sshdump could give a more accurate error message when key passphrase is missing

Summary

When I use SSH remote capture: sshdump from the Wireshark GUI with an passphrase-protected key, but leaving the passphrase field blank, it fails with

Error by extcap pipe:  ** (sshdump:22948) 13:59:17.155770 [sshdump WARNING] ../extcap/sshdump.c:210 -- ssh_open_remote_connection(): Error creating connection.
 ** (sshdump:22948) 13:59:17.156072 [sshdump WARNING] ../extcap/sshdump.c:231 -- ssh_open_remote_connection(): Can't find a valid authentication. Disconnecting.

Steps to reproduce

See Summary.

What is the current bug behavior?

See Summary.

What is the expected correct behavior?

Report the passphrase is missing, or even better, prompt the user to type in the passphrase (for both the sshdump cli and Wireshark GUI).

Sample capture file

(If possible attach a sample capture file showing this issue)

Relevant logs and/or screenshots

Edited Jan 20, 2022 by Glen Huang

Источник

Hi, I’m testing

nrf_sniffer_2.0.0-beta-1_51296aa
64-bit Windows 10 PC
J-Link v6.16c
64-bit Wireshark 2.4.3
PCA10031(v1.1.0, 2016.22, nRF51422 based dongle)
PCA10040 (flashed as NUS example to generate packets)

/////////////////////////////

— The good scenario

Dongle

The LED LD1 shows the status of the dongle.

I observed that if the LD1 indicates purple only, Wireshark can detect the COMx interface.

Working

After I select COM6, LD1 starts to blink like this. A white color was added periodically.

Looks like this indicates that the dongle is capturing packets.

So I can sniff packets with the dongle.

— Close Wireshark 2 and rerunning it

When LD1 was blinking, Wireshark 2 captured packets. I closed and reopened Wireshark 2.

Sadly, Wireshark cannot detect COM6 unless I plug the dongle out and connect it back.

— ETC: Timed out message

Log

I connected my dongle and the PCA10040 which is flashed with the NUS (Nordic UART Service) example.

My iPhone was able to detect the PCA10040’s advertisement.

Whereas Wireshark sometimes shows the above log message; Packet read timed out.

The dongle couldn’t sniff anything when this message appears.

— ETC: Error by extcap pipe

When LD1 is white, Wireshark 2 cannot detect COMx interface.

However, in some cases, it detects COMx interface. When I start sniffing it, the above Python error is thrown.

Added 1/31 : After connection, Wireshark 2 doesn’t capture discovery/characteristic packets

GIFDemo

I flashed the modified BLE UART example; if the central sends data, the nRF52 echoes back.

I connected the Dongle at the USB hub to show this demo; the result was same if I connect the dongle at the back of my desktop directly.

After pairing, Wireshark 2 doesn’t update captured packets anymore.

However, after disconnecting both devices, the ADV packets are captured.

//////////////////

In short

1.Do I always have to turn off and on the dongle before running Wireshark 2?

Without this off/on process, Wireshark 2 fails to find the COMx interface, regardless when the PCA10040 (COM5) was disconnected.

2.Is there a reason for observing the timed out message?

3.Although I have connected the dongle to the DELL’ monitor’s USB hub, is the hub a reason for creating that Python exception?

I wish to know the reason for this problem, too.

-Regards, MANGO

Источник

Wireshark
mailing list archives

From: hdv <henri.de.veer () gmail com>

Date: Wed, 9 Jan 2019 21:42:20 +0100

On 4-1-2019 00:10, Dario Lombardo wrote:

On Thu, Jan 3, 2019 at 5:36 PM hdv <henri.de.veer () gmail com
<mailto:henri.de.veer () gmail com>> wrote:

    I really would expect that the stderr channel could be used to
    report errors in some way. Tested it, does not display anything
    until you stop the capture. It would be better to display it
    immediately. You should assume when anybody uses a plugin we can
    report errors to the user in a sensible matter. The end user
    should not need to enable debugging or build the code to get
    errors. I my example I want to report an error to the user when
    the plugin cannot make a connection to the external device for
    example.

    ...<deleted>...

    So what is the status of the current extcap plugins, are they
    still all functional? I can imagine they are harder to test
    because some are proprietary/need special hardware.

They’re expected to be. If they are not, feel free to open bugs on
bugzilla. Extcaps in the source tree except ciscodump don’t require
special hardware at all.

An example of something that is not working as it should be (as far as
what I would expect) is the initial error handling, it looks plain broken.

For example take the «ssh remote capture plugin» where you can easily
reproduce what I mean: Start it and just fill in an IP number of
something that does not exist.

My expectancy is that I will get an error after, say 30 seconds or so
that the tool cannot connect.

Instead Wireshark shows in the left lower corner: <live capture in
progress> and on the right: «No packets» forever…………….

In the process manager you see 3 processes:
Wireshark/Dumpcap/sshdump.exe after some time sshdump vanishes from the
process list (time out).

But nothing happens. Only when you explicitly stop the capture (Stop
red square) it shows an error:

«Error by extcap pipe: **(sshdump.exe:25304): WARNING **: Error creating
connection.

I would expect wireshark to stop immediately when the pipe is broken. By
the way this behavious is on WINDOWS, maybe the *nix port is functioning
as expected?

Can somebody confirm this?

I assume this is an error to report in bugzilla.

Regards,

Henri

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread:

Re: Cannot get external capture (extcap) interface to work with my new plugin. hdv (Jan 02)
- Re: Cannot get external capture (extcap) interface to work with my new plugin. Dario Lombardo (Jan 02)
  - Re: Cannot get external capture (extcap) interface to work with my new plugin. hdv (Jan 03)
    - Re: Cannot get external capture (extcap) interface to work with my new plugin. Dario Lombardo (Jan 03)
    - Re: Cannot get external capture (extcap) interface to work with my new plugin. hdv (Jan 04)
    - Re: Cannot get external capture (extcap) interface to work with my new plugin. hdv (Jan 04)
    - Re: Cannot get external capture (extcap) interface to work with my new plugin. hdv (Jan 04)
    - Re: Cannot get external capture (extcap) interface to work with my new plugin. hdv (Jan 09)

Источник

In my review of the iHealth glucometer I pointed out that I did indeed check if the app talked with the remote service over TLS or not. This was important because if it didn’t, it meant it was sending medical information over plaintext. There are a few other things that can go wrong, they can for instance not validate the certificate provided over TLS, effectively allowing MITM attacks to succeed, but that’s a different story altogether, so I won’t go there for now.

What I wanted to write about is some notes about my experience, if nothing else because it took me a while to get all the fragments ready, and I could not find a single entry anywhere that would explain what the error message I was receiving was about.

First of all, this is about the Wireshark tool, and Android phones, but at the end of the day you’ll find something that would work almost universally with a bunch of caveats. So make sure you get your Wireshark installed, and make sure you never run it as root for your own safety.

Rick suggested to look into the androiddump tool that comes with Wireshark; on Gentoo that requires enabling the right USE flag. This uses the extcap interface to “fetch” the packets to display from a remote source. I like this idea among other things because it splits the displaying/parsing from the capturing. As I’ll show later, this is not the only useful tool using the interface.

There are multiple interfaces that androiddump can capture from; that does include the logcat output, that makes it very useful when you’re debugging an application in realtime, but what I cared about was sniffing the packets from the interfaces on the device itself. This kept failing with the following error:

Error by extcap pipe: ERROR: Broken socket connection.

And no further debugging information available. Googling for a good half hour didn’t bring me anywhere, I even started strace‘ing the process (to the point that Wireshark crashed in a few situations!) until I finally managed to figure out the right -incantation- invokation of the androiddump tool… that had no more information even in verbose mode, but at least it told me what it was trying to do.

The explanation is kind of simple: this set of interfaces is effetively just a matrioska of interfaces. Wireshark calls into extcap, that calls into androiddump, that calls into adb, that calls into tcpdump on the device.

And here is the problem: my device (a Sony Xperia XA from 3 Ireland) has indeed a tcpdump command, but the only thing it does is returning 1 as return value, and that’s it. No error message and not even a help output to figure out if you need to enable somethihng. I have not dug into the phone much more because I was already kind of tired of having to figure out pieces of the puzzle that are not obvious at all, so I looked for alternative approaches.

Depending on the working system you use to set the capture up, you may be able to set up your computer to be an access point, and connect the phone to it. But this is not easy particularly on a laptop with already-oversubscribed USB ports. So I had to look for alternatives.

On the bright side, my router is currently running OpenWRT (with all the warts it has). Which means I have som leeway on the network access already. Googling around would suggest setting up a tee: tell iptables to forward a copy of every single packet coming from or to the phone to another mac address. This is relativel expensive, and no reliable over WiFi networks anyway, beside increasing congestion on an already busy network.

I opted instead to use another tool that is available in extcap: ssh-based packet captures. In Gentoo these require the sshdump and libssh USE flags enabled. With this interface, Wireshark effectively opens a session via SSH to the router, and runs tcpdump on it. It can also use dumpcap or tshark, which are Wireshark-specific tools, and would be significantly more performant, but there is no build for them on OpenWRT so that does not help either.

While this actually increases the amount of traffic over WiFi compared to the tee option, it does so over a reliable channel, and it allows you to apply capture filters, as well as start and stop capture as needed. I ended up going for this option, and the good thing with this is that if you know the hardware addresses of your devices, you can now very easily sniff any of the connected clients just by filtering on that particular address, which opens for interesting discoveries. But that’s for another day.

Источник

wireshark ssh remote connect on linux server

First, install the optional component from Tools section of Wireshark installer

Then, select config gear of the SSH remote capture from the welcome screen

Configure the following information:

Server ip/hostname and port

Remote user name and private rsa key in OpenSSH format (use puttygen > conversions > export openssh key)

(user and password should work too)

You shouldn’t have to change anything in Capture tab

If you get an error linked to Kex algos:

Error by extcap pipe:

** (sshdump.exe:8216): WARNING **: Error creating connection.

** (sshdump.exe:8216): WARNING **: Connection error: kex error : no match for method kex algos: server [curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256], client [diffie-hellman-group14-sha1,diffie-hellman-group1-sha1]

You have to add the requested algorithms to the server or client.

I’ve handled it adding this line to /etc/ssh/sshd_config on the server:

KexAlgorithms +diffie-hellman-group1-sha1

Then reload the ssh server

Find full path of a file or folder in Google Drive Web Interface

If you want to see the full path where is located a file or folder from the Web Interface of Google Drive (e.g. from the Activity panel), simply select the file by checking it: Updated 20/02/2014 to reflect changes of the new version of Google Drive : When the file is selected, click on the Preview button on the top bar: Click on the Activity and Details button and select the Details tab : Some information about the file will be shown, as well as the folder where is located the file: If you click on the folder name, you will enter this folder and the full path will be shown on the top of the screen:

Resolve «Cannot download packages whilst offline» issue in Deja-Dup backup software

If you got the error message «Cannot download packages whilst offline» but your internet connection is active, this is probably because you’ve managed the network configuration yourself and the network manager is reporting an offline status even if it’s not correct. To fix this issue, simply edit the file /etc/NetworkManager/NetworkManager.conf and change the following configuration to be inline with: [ifupdown] managed=true Then restart the Network Manager : sudo service NetworkManager restart #1

ubuntu 20.04 / netplan / change mac address and static ip

I wasn’t able to set together a virtual mac address and a static IP using netplan: either the mac address didn’t change, or IP was not set. I finally got the trick using a fake nic definition that matches the new virtual mac address I’ve set. network: renderer: networkd ethernets: ens160: match: macaddress: 00:0c:29:5a:69:00 macaddress: 00:50:56:0c:de:a6 ens160_2: match: macaddress: 00:50:56:0c:de:a6 addresses: [ 139.99.5.72/32 ] nameservers: addresses: [ 8.8.8.8 ] routes: — to: 0.0.0.0/0 via: 139.99.5.254 on-link: true ens192: addresses: [192.168.103.14/24] #dhcp4: true version: 2

Источник

I wanted to use the WLANPi as a remote Wireshark capture adapter for the first time recently so I got stuck in. However, I hit an error that returned very little information when I googled it. Once I’d been shown the resolution I figured I’d document it here to help others (and no doubt myself when this happens again).

First off, if you are a network engineer and you don’t know what the WLANPi is then go here, read about it, and acquire one, because this thing is awesome. It might have WLAN in the title but there are so many tools on there for testing the LAN itself that every network engineer should carry this $50 gadget! Right now (Nov 2020) there is a hardware availability issue as the original components are discontinued, but the team are working hard to find a new platform for it, so by the time you read this you should be able to get one I hope.

I wanted to use the WLANPi as a remote capture device because Windows is less than stellar at this job. You can find a neat little Wireshark plugin here that makes this super easy. And a video here that gives you instructions/a demo.

I chose to test the USB OTG method of connecting the WLANPi as described by Nigel in the video as will be the simplest method when onsite. However, I was getting an SSHDump error when trying to start a capture. The error was:

Error by extcap pipe:
** (sshdump.exe:29552): WARNING **: Error creating connection.
** (sshdump.exe29552): WARNING **: Connection error: Timeout connecting to 169.254.42.1

(in the screenshot above uses I used a slightly different IP address to force the error after I had fixed it. Originally the error had IP 169.254.42.1 and a different random port. Otherwise the error is exactly the same)

What should happen when using the OTG port is that the WLANPi gives itself an IP of 169.254.42.1, a new network adapter gets installed on the laptop, and that network adapter gets given an IP of 169.254.42.2. But I wasn’t getting a new network adapter installed by the OTG connection. I was getting a new Com adapter installed in Device Manager but this is not enough.

If you think you’re having this problem you can test this yourself by doing an ‘ipconfig’ and looking for an address starting 169, and trying to ping 169.254.42.1 which should fail.

If you are having this issue then you just need to use a different driver for the Com adapter. You can download the driver from this Google drive share. You then need to head into Device Manager, find the Com adapter that has been installed, and update the driver using the files you downloaded.