Each entry names the cause rather than restating the symptom. Several of these are not faults in the software at all — a switch that does not advertise, or a Windows permission — and saying so is more useful than a list of things to try.
The capture driver is not installed. Windows will not show raw frames without it.
Install it from npcap.com, then restart CySecTek so it picks the driver up. Full steps are in installing Npcap.
If you already have Wireshark, you already have Npcap — in that case the likely problem is that CySecTek was open before the driver was installed. Restart it.
Windows only exposes raw capture to an elevated process.
Close CySecTek, right-click it and choose Run as administrator, then try again.
This is the only feature that needs elevation. If scanning, SSH, file transfer or the servers are misbehaving, administrator rights are not the answer and something else is wrong.
Usually the credential, but on network equipment it is often the account or the method.
If the failure happens before any credential is sent, it is not an authentication problem. A connection refused at negotiation is a different error, and if you are on an older release see no common key exchange algorithm.
The device is presenting a different key than the one pinned on first connect.
This is the app doing its job. A changed host key means either the device was genuinely rebuilt or replaced, or something is sitting between you and it.
The panel shows the stored fingerprint and the new one side by side. Verify the new fingerprint against the device itself — over the console, or from whoever rebuilt it — before accepting the change. Comparing it against what the connection just told you proves nothing, because that is the thing in question.
Once you have confirmed it, accept the change and the new key is pinned in place of the old one.
Usually a PuTTY .ppk, an encrypted key with no passphrase entered, or a wrong passphrase.
The message names which of these it is. In order of how often they happen:
.ppk does not help — detection is on content.See using SSH keys.
A version before 0.7.1 against equipment offering older key exchanges.
This affected most enterprise network hardware and all older kit, and it read like a network fault when it was not one. It is fixed in 0.7.1: both the terminal and file transfer now negotiate the algorithms equipment actually offers, modern ones first.
Update to the current release. If you see this on 0.7.1 or later, the device is offering something genuinely obsolete — tell us what it is.
Windows Firewall is blocking the inbound traffic, usually because the prompt was dismissed.
Windows prompts the first time a server binds. If that prompt was dismissed, or answered for the wrong network profile, the rule is not there and the server sits waiting for traffic that never arrives.
Also confirm you bound to the interface the device is actually on. A server bound to your Wi-Fi address will not answer anything arriving on the Ethernet bench link.
Often the switch is not advertising — but rule out the cheaper causes first.
If all of that is right, the switch is not advertising. LLDP and CDP are frequently disabled on access ports, and there is nothing the app can do about it — the information is not on the wire. Ask whoever runs the switch to enable LLDP, or read the port from the switch side.
Windows gives a COM port to whoever opened it first.
Close whatever else has it — PuTTY, another terminal, or a vendor configuration tool are the usual suspects. Some vendor utilities hold the port open in the background after their window has gone.
If nothing obvious has it, unplug and replug the adapter, then press Refresh. Windows sometimes leaves a port claimed after a program exits badly.
The view is bound to an adapter that no longer exists.
Press Refresh on the screen you are on. Adapter lists are read when the screen opens and after a refresh, not continuously, so a cable pulled or a dock removed mid-session leaves a stale list.
A running capture or a bound server does not follow an adapter that goes away. Stop it, refresh, and start it again on the adapter you now have.
Windows requires Location Services before it returns scan results to an application.
This is a Windows rule, not a choice the app makes, and it applies to every wireless scanning tool on the platform.
On a managed machine this is sometimes disabled by policy, in which case wireless scanning will not work until that policy changes.
The downloaded package did not match the expected hash, so it was discarded.
The updater hashes what it downloads and compares it against the manifest before applying anything. A mismatch means the file is not what we published — most often an interrupted or proxy-mangled download, occasionally something worse.
It is discarded rather than installed, which is the correct outcome. Try again on a different connection. If it keeps failing, download the installer manually from the download page and check the hash yourself.
Either the wrong app password, or a store written by a key that no longer exists.
First, make sure the app password is right — the app cannot distinguish “wrong password” from “unreadable data” from the outside, because both look like decryption failing.
If the password is definitely correct and entries still will not decrypt, the store was written under a key that is gone — for example after restoring a profile from another machine. The entries themselves survive; the stored passwords do not. Use Forget password on the affected entries and re-enter them as you use each device.
There is no recovery path for the app password itself, by design. See managing credentials.
Send what you are seeing to info@cysectek.com — the exact message, the version from the About screen, and what you were doing. If it is reproducible it gets fixed.