I use Whonix to perform OSINT on the Tor network via OnionSearch, Onioff, etc.
I have connection problems when using these tools. For example for OnionSearch, I get:
OnionSearch also queries for Onionland, the execution bar increases to a certain percentage, then it stops and shows the connection error above, it's as if the connection is unstable! Very weird
Then, for Onioff, I have the error message : Unsuccessful Tor connection
However, I do have access, via the Tor browser, to the onion links, and the Tor service is also working correctly.
Does anyone have an idea where the problem could come from or rather in what should I dig to seek the resolution?
Related
I am using Indy to connect to an Ftp server. We have had problems with the server being down, creating a "Host not found" error, which I handle and indicate to the user, however, today the software was installed on a computer that did not have an internet connection. The error produced when I "Connect" is also "Host not found", which is not totally correct. Is there a function/procedure I can call inside the TIdFtp component that will tell me if there is actually a connection to the internet so I can display an error indicating the user is not connected? I am using Delphi XE Seattle.
I have looked through the list of IdFtp properties/functions etc, but nothing seems obvious.
Is there a function/procedure I can call inside the TIdFtp component that will tell me if there is actually a connection to the internet so I can display an error indicating the user is not connected?
No. What you will have to do is attempt a TCP connection to several different servers and see if any of them succeed or if they all fail. For instance, you can use TIdTCPClient to connect to well-known server ports that are pretty much guaranteed to be online 99+% of the time, like google.com/yahoo.com on port 80 (HTTP) or 443 (HTTPS), etc.
Error Screenshot I have recorded test scrip using smart meter.
But I when I tries to load the script "Rum smartmeter Test"
It gives following. I have no requirement of remote server as i wanted to run basic Testscript from local machine
*> Connection refused to host: 127.0.0.1; nested exception is:
java.net.ConnectException: Connection refused connect*
Just for the background please note that SmartMeter.io is based on Apache JMeter but adds new features such as one-click test reports, advanced scenario recorder, user friendly distributed mode, acceptance criteria and many others.
Looking forward for your suggestion.
Thanks.
Looks like SmartMeter is unable to start a load generator. The most common reason is that the required port 1099 is already occupied by some other program or the load generator can sometimes be blocked by your firewall. I suggest you restart your computer and try again. If it doesn't help, then you need to find out what is occupying that port. See for example How can you find out which process is listening on a port on Windows?
You should be able to get some information from logs/generator.log.
You can also run tests from SmartMeter Editor, the same way you would do in JMeter.
I'm working to create a video calling web app using WebRTC.
The communication is working fine on same network. But when communicating in different network I'm getting ICE failed error.
Error: ICE failed, see about:webrtc for more details
In about:webrtc I' able to get local and remote SDP's, but ICE State is failed. http://imgur.com/a/nPPDr
Here is the code of my main.js file
Here is the my log file from about:webrtc
P.S: Before posting the question I've checked several posts in SO and in other sites but no one did the trick.
Looking at the log file you provided it looks like you provided a TURN server, but the communication with that TURN server simply times out. So either something like a local firewall is blocking the communication with your TURN server or your TURN server is not working.
In case your local firewall blocks UDP traffic it might help to configure and use TURN TCP additionally to get through the firewall.
your about:webrtc does not show any relay candidates gathered from a TURN server. At the risk of sounding like a broken record: you need a TURN server for the majority of connections between different networks.
We are attempting to connect to a WebDAV server using net use over SSL. On some servers we're seeing an issue in which this connection only succeeds if we specify port 443 in the URL.
Does Map
net use * "https://example.com:443/folder"
net use * "\\example.com#SSL#443\folder"
and, bizarrely, so does this:
net use * "\\example.com#SSLasdf\folder"
Does Not Map
net use * "https://example.com/folder"
net use * "\\example.com#SSL\folder"
In the non-working cases we consistently receive the following error:
System error 67 has occured.
The network name cannot be found.
We have noticed some things that might be useful information:
We have a test server that's configured the same way as the prod server and it works as expected.
In the non-working cases, no incoming requests are ever seen at the prod server from the failing host.
All clients are based on the same image.
The problem does not manifest uniformly on all clients -- some work, some don't.
There is an existing, valid entry for example.com in the client DNS cache.
Flushing the client DNS cache of the affected servers does not resolve the problem.
Once the problem appears, it seems to stick. That is, if I execute one of the working mappings, delete it, and then immediately execute one of the non-working mappings, the problem persists.
We are utterly stumped. Any theories?
You are seeing different behaviors because you are connecting using different names. Once a name has been attempted and failed, the WebClient (this is the service that enables WebDAV) will cache the response for a period. To clear the cache, locate the WebClient service in the Services console and restart it. Or from an administrative command prompt execute the following command:
net.exe stop webclient && net.exe start webclient
We ultimately determined that we were mis-interpreting the System Error 67 that net use was returning. We discovered two interesting things:
In the event that the WebDAV returns a 404 or a 50x on the initial, root folder PROPFIND, net use will (rightly) interpret this as the root folder being unavailable. The fact that it says the network name could not be found let us to believe that the problem was with the name resolution, but it was really just saying, 'hey, I couldn't find anything at this path.'
If 'net use' fails due to a 404/50x, it appears that for a brief period of time it will automatically fail any additional mappings for that same host without issuing a request. For example, if net use http://me.com/foo returns a 404, then net use http://me.com/bar will instantly fail if made in rapid succession to that first call, and no request record will be seen in the WebDAV server logs.
My best guess is that appending the #443 port didn't make any real difference. What it perhaps did do was to trick net use into thinking it was talking to a different host, at least for the purposes of its 'auto-fail' feature. But that's just a guess.
I am working on a Windows (Microsoft Visual C++ 2005) application that uses several processes
running on different hosts in an intranet.
Processes communicate with each other using TCP/IP. Different processes can be on the
same host or on different hosts (i.e. the communication can be both within the same
host or between different hosts).
We have currently a bug that appears irregularly. The communication seems to work
for a while, then it stops working. Then it works again for some time.
When the communication does not work, we get an error (apparently while a process
was trying to send data). The call looks like this:
send(socket, (char *) data, (int) data_size, 0);
By inspecting the error code we get from
WSAGetLastError()
we see that it is an error 10054. Here is what I found in the Microsoft documentation
(see here):
WSAECONNRESET
10054
Connection reset by peer.
An existing connection was forcibly closed by the remote host. This normally
results if the peer application on the remote host is suddenly stopped, the
host is rebooted, the host or remote network interface is disabled, or the
remote host uses a hard close (see setsockopt for more information on the
SO_LINGER option on the remote socket). This error may also result if a
connection was broken due to keep-alive activity detecting a failure while
one or more operations are in progress. Operations that were in progress
fail with WSAENETRESET. Subsequent operations fail with WSAECONNRESET.
So, as far as I understand, the connection was interrupted by the receiving process.
In some cases this error is (AFAIK) correct: one process has terminated and
is therefore not reachable. In other cases both the sender and receiver are running
and logging activity, but they cannot communicate due to the above error (the error
is reported in the logs).
My questions.
What does the SO_LINGER option mean?
What is a keep-alive activity and how can it break a connection?
How is it possible to avoid this problem or recover from it?
Regarding the last question. The first solution we tried (actually, it is rather a
workaround) was resending the message when the error occurs. Unfortunately, the
same error occurs over and over again for a while (a few minutes). So this is not
a solution.
At the moment we do not understand if we have a software problem or a configuration
issue: maybe we should check something in the windows registry?
One hypothesis was that the OS runs out of ephemeral ports (in case connections are
closed but ports are not released because of TcpTimedWaitDelay), but by analyzing
this issue we think that there should be plenty of them: the problem occurs even
if messages are not sent too frequently between processes. However, we still are not
100% sure that we can exclude this: can ephemeral ports get lost in some way (???)
Another detail that might help is that sending and receiving occurs in each process
concurrently in separate threads: are there any shared data structures in the
TCP/IP libraries that might get corrupted?
What is also very strange is that the problem occurs irregularly: communication works
OK for a few minutes, then it does not work for a few minutes, then it works again.
Thank you for any ideas and suggestions.
EDIT
Thanks for the hints confirming that the only possible explanation was a connection closed error. By further analysis of the problem, we found out that the server-side process of the connection had crashed / had been terminated and had been restarted. So there was a new server process running and listening on the correct port, but the client had not detected this and was still trying to use the old connection. We now have a mechanism to detect such situations and reset the connection on the client side.
That error means that the connection was closed by the
remote site. So you cannot do anything on your programm except to accept that the connection is broken.
I was facing this problem for some days recently and found out that Adobe Acrobat Reader update was the culprit. As soon as you completely uninstall Adobe from the system everything returns back to normal.
I spent a long time debugging a 10054/10053 error in s3 pre-signed uploads
Turns out that the s3 server will reject pre-signed s3 uploads for the first 15 minutes of it's life.
So - If you're debugging s3 check it's not a new bucket.
If you're debugging something else - this is most likely a problem on the server side not client side.