I had a project which used windivert to work as a router in my network, and it worked fine but now is dead with the same code. Previous versions which worked succesfully now dont work. I always get the same Windivert error which is 997 (Overlapped I/O operation is in progress).
For example when I use WindivertOpen I get the error, when I restart the computer to reset the windivert driver I dont get the error 997 in WindivertOpen but I get it in WindivertSend or WinDivertSendEx and after use them I again get the error in WindivertOpen. These functions worked fine for me months ago and my router worked as I expected, but now I am done with these errors, there is nothing I can do, maybe this is caused by a windows security update.
I need to know how to reset the driver without restart the computer and to know what I can do to face this problem. I used windivert to block windows TCP RST packets to my router fordwards, windows does this when there is not sockets associated with the ports that you are fordwarding, what can I do to block this packets without windivert or with a working way of windivert?
The 997 error is ERROR_IO_PENDING, but the error code is meaningless unless WinDivertOpen returns INVALID_HANDLE_VALUE. Otherwise the call will have completed successfully.
Presumably you have upgraded to WinDivert 1.4 from a previous version. Simply replacing the binary files (dll/sys) won't work -- you must instead recompile your program against the new API.
Related
I'm trying to get my head around SNMP for a project I'm working on. After I failed miserably getting it to work in my company's network, I set up a simple 3-device network to test things on, consisting of two Windows 10 PCs and a manageable switch between them.
I installed the optional feature "SNMP" on both PCs, made sure the service is running correctly and configured both services to accept SNMP queries from each other. I made sure to open up UDP port 161 in both PCs firewalls. Then I got the Net-SNMP binaries in order to use SNMPGET and SNMPWALK. As an alternative, I set up the SNMP extension for PHP through xampp (since I want to use PHP in my project once I get SNMP to work). Finally, I installed wireshark to monitor what exactly is going on and this is what I found:
When I try SNMPGET or SNMPWALK either through cmd or as a PHP command, I always get a timeout message. Wireshark is showing the get-next-request leaving one PC and arriving correctly on the other, so the network connection itself is working fine. But the receiving PC never sends a response. As I said, I'm pretty new to SNMP and I'm at a loss as to why this is happening. As I understand it, the optional feature for Windows 10 comes with its own SNMP agent, correct? If so, what could cause it to simply ignore an incoming request from a valid source IP?
The funny thing is that this even happens when I try to send an SNMP query to 127.0.0.1. I have no idea what I'm doing wrong...
Thanks to the comment of Lex Li, I was able to finally figure out which step I made a mistake with:
When setting up the SNMP service, under the security tab, I had to add 'public' as an accepted community name (with READ-ONLY rights). I figured since 'public' is sort of the standard read-only community, it would be accepted by default, which apparently it is not.
Alternatively, I guess I could have added my own communtiy name, but I didn't try that since I only want to read some values through SNMP anyways and read-only access is all I need for that.
Thank you very much Lex Li, I'm off to continue my project now!
We recently observe rare UDP communication issues that show the following symptoms:
A socket sendto() call fails with error WSAENOBUFS (10055)
A subsequent recvfrom() call on this socket does not receive anything, even though Wireshark shows that the network interface actually received the expected datagrams. This situation persists for approximately 8 seconds, afterwards new incoming datagrams can be received again from the socket.
In Windows System Log, there appears a Kernel-General information entry at the time of the sendto() error:
The access history in hive \??\C:\ProgramData\Microsoft\Provisioning\Microsoft-Desktop-Provisioning-Sequence.dat was cleared updating 0 keys and creating 0 modified pages.
The issue happens on a customer system running Microsoft Windows 10 Pro for Workstations, Version 10.0.17763 Build 17763.
On that system we were able to reproduce the issue with a simple test program written in C++ that echoes UDP datagrams. We verified that the thread receiving from the socket was actually responsive all the time, by specifying a timeout of 1 second using SO_RCVTIMEO, printing some “still alive” output and immediately calling recvfrom() again.
On our own test system, we were unable to observe the issue under the same circumstances as the customer. However, we were able to provoke similar effects when playing around with the network adapter settings while the test was running. Enabling Microsoft LLDP Protocol Driver showed the sendto() error and sometimes also resulted in the 8 second “silence” period, but without any Windows System Log entry.
Any hints are greatly appreciated.
The issue seems to be related to Microsoft Provisioning Tool since Windows 10 1809.
Disabling it fixed the issue in our case:
Open Task Scheduler, go to Microsoft/Windows/Manangement/Provisioning and disable Logon task.
Source: Windows TenForums
I am using a simple UDP Receiver code built in c++. I upgrade on of my machines to Windows 7 and this line is now getting held up because the UDP stream is not getting through to the executable running:
iResult = recv(sock, RxBuf, buffsize, 0);
The recv function is just held up. I have used wire shark to make sure the UDP stream is active and correct but don't know what the problem is.
Any help would be appreciated.
(the UDP stream is broadcasted)
Unless you have set sock to non-blocking, recv() will block until data is received. So if the program is blocking there, its probably because it isn't receiving any datagrams.
A lot changed in Windows networking between XP and 7, so here some things to check:
Check your bind() statement. Make sure you are really binding the port you think you are and that you are checking for errors.
Simply turning off the firewall in Windows does not completely disable it. There are many components, especially on Vista and later, which are active all the time.
When you first run an executable, Windows Vista and later will ask you to confirm that it should have network access. If you click anything other than "Allow", then the path to that executable may be blocked forever. Adding an "Allow" rule does not override this block. To unblock it, you must turn the firewall back on, and dig down to "Windows Firewall with Advanced Security" to delete the offending rules from both Incoming and Outgoing. You might be amazed at what can build up in there.
You probably need to add an Incoming firewall rule for the UDP port that you are listening on. Even if the firewall is turned off.
Other things to try: disable any anti-virus software, run your listener as Admin, get Wireshark or another packet sniffer to make sure the packets really are reaching the machine.
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.
I'm working with an embedded system which has a RAS entry already set up, using the API function RasDial from rasapi32.dll.
All works well except if something goes wrong after RasDial and before RasHangUp. In this case any further attempt to dial is met with error 756 "connection is being dialled", whether the dial attempt is done via the API or via the Windows rasdial command line utility.
rasdial connectionname /d doesn't help either.
The com port used for the modem is locked.
The only way to recover is to reboot.
Obviously under normal circumstances the solution is to make sure that RasDial is always followed by RasHangUp. But for cases where this doesn't happen, is there a way of aborting the dial attempt? For example, if the app calls RasDial and then crashes, how do I get out of that other than by rebooting?
Unfortunately, unless your application can properly terminate the connection that's in progress before exiting the RAS state machine becomes corrupted and must reboot to fix the problem. I've noticed that Windows 7 handles these sorts of scenarios better than XP and Vista did, but there are still occasions when I've had to reboot.
I've managed to prevent most of these sorts of problems with the DotRas API as long as they're occuring in the event handlers of the RasDialer, but if the application crashes from another thread and not from the background thread which raises the RasDialer events, there's nothing I can do about that.
For asynchronous dialing using the DotRas 1.2 SDK:
using DotRas;
RasDialer dialer = new RasDialer();
dialer.EntryName = "My Connection";
dialer.Credentials = new NetworkCredential("My", "User");
dialer.DialAsync();
From this point you can call dialer.DialAsyncCancel() if you want to cancel the connection attempt that's in progress.
For synchronous dialing using the DotRas 1.2 SDK is very similar to asynchronous dialing other than replacing the DialAsync call with simply dialer.Dial().
Here's a link to the API I was talking about: http://www.codeplex.com/DotRas
Hope that helps!