I am trying to simulate a scenario where connection to the server of one process is down while the connection to another server is up. Just pulling the network cable won't work in my case since I need another process connection to stay up.
Is there any tool for this kind of job? I am on Windows. Thanks!
There's a few layers which you can simulate this at. The easiest would be if your two servers listen on two distinct TCP ports. In that case, you could run two tcp proxies, and stop/pause one when you want to simulate a failure. For Windows I would suggest using tcpTrace to do this.
Another option would be to have the two servers bound to two virtual NICs, which are bridged to the physical NIC. Of course if you have two physical NICs, you could bind each server process to a different physical NIC.
At a lower level, you can ran a WAN simulator. Most simulators allow you to impair specific types of traffic or specific ports. One such simulator is Packetstorm.
One other method which I would suggest is attaching a debugger to one process, and halting all threads on the process with the debugger. Often, a process doesn't die, but gets stuck in garbage collection, or in a loop. As the sockets don't close, many 'high availability' solutions won't automatically failover.
One approach would be to mock the relevant network connection code for the purposes of testing. In this case you would probably want to mock it returning whatever it usually would if the connection was down.
A poor man's approach if you can use sleep/hibernate mode on your machine :
Set an Outbound rule in the Windows Firewall to disallow connection for a particular Program.
Already connected sockets stay connected: put the machine in sleep/hibernate mode for a brief moment to force those sockets to disconnect.
When the system is restored, the program cannot establish new connections.
New connections are made possible as soon as you disable the firewall rule.
Note that it does not simulate network outage because each connection fails immediately with an permission error. But it prevents a process to establish connections.
Related
Is it possible that windows leaks sockets connection and these sockets are not shown in tcpview and netstat?
After running a few applications that perform many network connections, my windows machine enters a state in whitch it in not able to open any new socket connection. Even to itself (localhosts).
For example, telnet to a local application failed because windows can't create new sockets.
Closing and restarting the network applications does not helps. Only full windows restart solves the problem.
netstat (& tcpview) indicates that there are only some dozens of connections.
Thanks for your help.
No, it is not possible for those apps to miss leaked connections. Something else is going on. Maybe you are not looking at their detailed views, like seeing closed sockets that are in TIME_WAIT state. If you cannot open new socket connections, you mostly likely are encountering port exhaustion. Wait some time for ports to time out and become available again. Or stop wasting ports in the first place.
I am trying to reverse engineer a third-party TCP client / server Windows XP, SP 3 app for which I have no source available. My main line of attack is to use WireShark to capture TCP traffic.
When I issue a certain GUI command on the client side, the client creates a TCP connection to the server, sends some data, and tears down the connection. The server port is 1234, and the client port is assigned by the OS and therefore varies.
WireShark is showing that the message corresponding to the GUI command I issued gets sent twice. The two messages bear a different source port, but they have the same destination port (1234, as mentioned previosuly).
The client side actually consists of several processes, and I would like to determine which processes are sending these messages. These processes are long-lived, so their PIDs are stable and known. However, the TCP connections involved are transient, lasting only a few milliseconds or so. Though I've captured the client-side port numbers in WireShark and though I know all of the PIDs involved, the fact the connections are transient makes it difficult to determine which PID opened the port. (If the connections were long-lived, I could use netstat to map port numbers to PIDs.) Does anybody have any suggestions on how I can determine which processes are creating these transient connections?
I can think of two things:
Try sysinternals' tcpview program. It gives a detailed listing of all tcp connections opened by all the processes in the system. If a process creates connections, you will be able to see them flash (both connect and disconnect are flashed) in tcpview and you will know which processes to start looking into.
Try running the binary under a debugger. Windbg supports multi-process debugging (so does visual studio I think). You may have only export symbols to work with but that should still work for calls made to system dlls. Try breaking on any suspected windows APIs you know will be called by the process to create the connections. MSDN should have the relevant dlls for most system APIs documented.
Start here... post a follow-up if you get stuck again.
I ended up creating a batch file that runs netstat in a tight loop and appends its output to a text file. I ran this batch file while running the system, and by combing through all of the netstat dumps, I was able to find a dump that contained the PIDs associated with the ports.
Are there any reasons for favoring named pipes over sockets for local IPC (both using win-api), effectiveness-wize, resource-wize or otherwise, since both behave very much alike (and likely to be abstracted by a similiar interface anyway), in an application that is likely to already use sockets for network purposes anyway?
I can name at least the addressing issue: port numbers for sockets against filenames for pipes. Also, named pipes (AFAIK) won't alert the firewall (block/unblock dialog), although blocked applications can still communicate via sockets locally. Anything else to take into account?
In the case of using sockets, are there any winsock settings/flags that are recomended when using sockets locally?
Some subtle differences:
Sockets won't work for local IPC if you don't have a functioning adapter. How common is it to have a PC without a functioning adapter? Well, I got bitten when somebody tried to demonstrate our software to a customer on a laptop that was not plugged in to a network or a power supply (so the OS disabled the network card to save power) and the wireless adapter was disabled (because the laptop user didn't use wireless). You can get around this by installing a loopback adapter but that's not ideal.
Firewall software can cause problems with establishing TCP/IP connections. It's not supposed to be an issue for local IPC, but I'm not convinced. Named pipes can have firewalls too.
You may have issues due to the privileges needed to create named pipes, or to create new instances of named pipes. For instance, I was running multiple servers using the same named pipe (probably not a good idea, but this was for testing) and some failed in CreateNamedPipe because the first server to create the pipe was running in Administrator mode (because it was launched from Visual Studio in Administrator mode) while the rest were launched from the command line with normal UAC level.
Although the article mentioned by Rubens is mostly about IPC over a network, it does make the point that "Local named pipes runs in kernel mode and is extremely fast".
Another solution you may want to consider is a named shared memory region. It is a little bit of work because you have to establish a flow control protocol yourself, but I have used this successfully in the past where speed was the most important thing.
I have a application which I suspects to get into problems because network nodes closes its sockets to various other servers it communicates to.
I would like to mimic that behaviour by shutting down one or severel connections that can be seen in netstat.
I'm not an expert in networking on OS level, so this question may be stupid, if so do you have any other suggestion on how to mimic the situation?
Before attempting to simulate the problem, you can diagnose the situation with certainty by using Wireshark or, on *nix, tcpdump. You should be able to capture the traffic and observer whether one of the server(s) is sending you a RST or not.
If you are receiving RST then this may be due to the servers themselves (time-outing and closing the connection while waiting for you to send them a response or data, or closing the connection because of server bugs or load limits), to your ISP's network equipment, or to your own network equipment (e.g. your wireless link going up and down.)
Disconnecting your router, network cable or wireless interface can simulate to various degrees connection issues that you can encounter at any time when talking to your servers. Disconnecting your PC's network cable should simulate a forceful closing of the connection with RST, whereas disconnecting a cable between you and the internet, but not the cable that directly connects your PC (e.g. disconnecting the cable between your router and your cable/DSL modem, or disconnecting the cable/DSL modem from the cable company's cable/telco's wall jack) will allow you to simulate timeout conditions.
You can use TCP View. You can view all the connections from your machine to another, or within the same machine. You can close a connection, thus breaking the connection.
alt text http://img440.imageshack.us/img440/6950/problemyd1.png
(The curly lines with dots represent a network route.)
Having a process called "foo.exe", is there a way to forward everything it communicates over TCP/IP to a forwarding proxy located elsewhere? This forwarding should not reflect to other processes.
Another question: if there are multiple network adapters, is it possible to force a process to use one specific adapter.
Since in this example the targethost.com is known, I could just edit "system32\drivers\etc\hosts" to map targethost.com's IP to localhost, where on port 8765 would be the first forwarder waiting for an incoming connection and pass everything forward to proxy.foo.com. I was wondering if there's a more elegant way of doing this.
This is not for malware, I'm doing some network testing with my complex home network. Thank you for warning us.
Some free software for this would be perfect, alternatively a code idea (native or .net). Thank you very much.
It's not too hard if you make your own computer a firewall, then your app connects to a port on your own computer, and that port is forwarded to both the original destination and logged or forwarded on to your spying computer.
Alternatively you can make your other computer the firwall and have it log/forward the info.
Finally you could use a sniffer.
SocksCap will probably do the job (if you're OK with establishing a SOCKS proxy at proxy.foo.com).
You could hook into the TCP stack, for example, by using the Windows Filtering Platform or its predecessors, or you could substitute the network libraries/calls of that particular process.