We make a line of industrial manufacturing products which are controlled from software running on a PC. The PC software, in turn, can be controlled from Android devices via a TCP connection, so out on the factory floor workers can use these Android devices as a remote controls for the manufacturing process.
One problem we have is that in congested networks, like at trade shows where we show these products off, the TCP connections between the Android and the PC often gets dropped. We've just written software to detect dropped TCP connections from the Android and send a message to the PC via UDP that this has occurred, but we need to test it.
To aid in testing this I want a way to shut down or break TCP on the PC so I can simulate this condition. I'd like to do this either as a simple C#/.Net program or, better yet, via a "DOS" command or something similar. Any suggestions on how to do this?
Related
Summary:
I am guessing that the issue here is something to do with how Windows and Linux handle TCP connections, or sockets, but I have no idea what it is. I'm initiating a TCP connection to a piece of custom hardware that someone else has developed and I am trying to understand its behaviour. In doing so, I've created a .Net core 2.2 application; run on a Windows system, I can initiate the connection successfully, but on Linux (latest Raspbian), I cannot.
It appears that it may be because Linux systems do not try to retry/retransmit a SYN after a RST, whereas Windows ones do - and this behaviour seems key to how this peculiar piece of hardware works..
Background:
We have a black box piece of hardware that can be controlled and queried over a network, by using a manufacturer-supplied Windows application. Data is unencrypted and requires no authentication to connect to it and the application has some other issues. Ultimately, we want to be able to relay data from it to another system, so we decided to make our own application.
I've spent quite a long time trying to understand the packet format and have created a library, which targets .net core 2.2, that can be used to successfully communicate with this kit. In doing so, I discovered that the device seems to require a kind of "request to connect" command to be sent, via UDP. Straight afterwards, I am able to initiate a TCP connection on port 16000, although the first TCP attempt always results in a RST,ACK being returned - so a second attempt needs to be made.
What I've developed works absolutely fine on both Windows (x86) and Linux (Raspberry Pi/ARM) systems and I can send and receive data. However, when run on the Raspbian system, there seems to be problems when initiating the TCP connection. I could have sworn that we had it working absolutely fine on a previous build, but none of the previous commits seem to work - so it may well be a system/kernel update that has changed something.
The issue:
When initiating a TCP connection to this device, it will - straight away - reset the connection. It does this even with the manufacturer-supplied software, which itself then immediately re-attempts the connection again and it succeeds; so this kind of reset-once-then-it-works-the-second-time behaviour in itself isn't a "problem" that I have any control over.
What I am trying to understand is why a Windows system immediately re-attempts the connection through a retransmission...
..but the Linux system just gives up after one attempt (this is the end of the packet capture..)
To prove it is not an application-specific issue, I've tried using ncat/netcat on both the Windows system and the Raspbian system, as well as a Kali system on a separate laptop to prove it isn't an ARM/Raspberry issue. Since the UDP "request" hasn't been sent, the connection will never succeed anyway, but this simply demonstrates different behaviour between the OSes.
Linux versions look pretty much the same as above, whereby they send a single packet that gets reset - whereas the Windows attempt demonstrates the multiple retransmissions..
So, does anyone have any answer for this behaviour difference? I am guessing it isn't a .net core specific issue, but is there any way I can set socket options to attempt a retransmission? Or can it be set at the OS level with systemctl commands or something? I did try and see if there are any SocketOptionNames, in .net, that look like they'd control attempts/retries, as this answer had me wonder, but no luck so far.
If anyone has any suggestions as to how to better align this behaviour across platforms, or can explain the reason for this difference is at all, I would very much appreciate it!
Nice find! According to this, Windows´ TCP will retry a connection if it receives a RST/ACK from the remote host after sending a SYN:
... Upon receiving the ACK/RST client from the target host, the client determines that there is indeed no service listening there. In the Microsoft Winsock implementation of TCP, a pending connection will keep attempting to issue SYN packets until a maximum retry value is reached (set in the registry, this value defaults to 3 extra times)...
The value used to limit those retries is set in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxConnectRetransmissions according to the same article. At least in Win10 Pro it doesn´t seem to be present by default.
Although this is a conveniece for Windows machines, an application still should determine its own criteria for handling a failed connect attempt IMO (i. e number of attempts, timeouts etc).
Anyhow, as I said, surprising fact! Living and learning I guess ...
Cristian.
I'm working on a legacy VB6 app that uses sockets to communicate to various devices.
On a 2012 system, we are noticing the time between calling winSock.Connect() to the connection event being fired is holding at about 9 seconds, across multiple systems on different domains.
On a 2008 R2 or lower system, it's taking 1-3 milliseconds between the call and the event being fired.
Has anyone run into this before, or has any ideas on what could be causing this?
I've done some snooping with Wireshark, and found that the first few TCP transmissions are not connecting and being retransmitted, not sure if that will help.
I ended up finding the answer to this after some extensive digging.
Starting in Windows Server 2012, Microsoft has enabled an extension of TCP called Explicit Congestion Notification (ECN). This allows end-to-end notification of network congestion with the loss of packets. The way this is enabled on a TCP packet is via a flag, which is defined in the definition of ECN (RFC 3168(2001)).
What was happening for me was that the devices my application talks to are older, and don't support the ECN flag. When they received packets with that flag enabled, they wouldn't acknowledge the transmission, leading to a timeout from the server. After two failed transmissions, it looks like Windows shuts off the ECN flag, and the device acknowledged the packets.
I disabled ECN running the following command from an Administrator Command Prompt:
netsh interface tcp set global ecncapability=disabled
There is nothing particularly "special" about the Winsock control, which is just a thin wrapper on top of the API. The only thing of note really is that it is 32-bit and must run inside WOW64.
You're probably doing something funny or all 32-bit programs using the winsock API the same way should see the same issue.
Perhaps you have a name resolution issue on this server?
I'm trying to make TCP socket keep alive in Windows Phone 8.1 using WinRT. But it don't seem no way to accomplished. I read the documents on MSDN (this) it say ControlChannelTrigger isn't supported on Windows Phone.
I'm sure there is a way to do this since Remote Desktop by Microsoft can be switched to other App and connection is still alive.
Thanks for advance.
TCP socket keep alive ... can be switched to other App and connection is still alive
I think you mix up concepts.
TCP socket keep alive is only to detect loss of connectivity to the peer.
What you see with Remote Desktop is that it maintains its own state over multiple TCP connections. But this kind of resuming has to be implemented by the application itself and in a application specific way.
I bought an Bluetooth ELM327 to read codes out of my cars diagnostic ports
I connect to it via Bluetooth in windows and it makes a serial-over-bluetooth com port 4
which any application running on my windows will connect quite happily.
I then found a few apps for the iphone and android etc that connect to these ELM gadgets via WIFI and not Bluetooth (because for some reason you cannot pair to these devices of iphone)
Now obviously I can buy a WIFI enabled ELM327 - but it costs £130 and my Bluetooth one cost £15
So after reading about this a bit I found out that the WIFI enabled ones you connect up as ad-hoc network and the smartphone(iphone) app tenets in port 23 that relays normal serial commands.
So obviously in the WIFI enabled one there must be some processor that runs an nano-os with telnet and some rs-323 translators and not sure what else.
How, using Windows 7 will i be able to relay any incoming WIFI requests for Telnet port 23 to my COM 4 that is connected to my Bluetooth ELM327 ..
As this is surely all that is needed by the Smartphone app.
You dont have to connect using a Bluetooth library like suggested ... because you are already connected to the device and have COM4 exposed to you. SO all you have todo is use a telnet library and translate and handle the handshake then realy the infomation as serial data.
There's no feature built in to Windows (or any other platform I know of) for such a scenario.
It would be fairly straightforward however to write a program to listen on port 23 and open a bluetooth connection when connected to, and then forward the data received on each connection out onto the other.
For instance one could use my .NET library 32feet.NET (e.g. http://32feet.codeplex.com/wikipage?title=General%20Bluetooth%20Data%20Connections etc etc) along with TcpListener from the .NET framework class libraries.
I want to monitor the HTTP traffic sent/received from my iPhone. The iphone is connected to the Internet via my wifi router.
I want to capture packets from my windows 7 station.
Thanks for your help.
You have a few options here:
If your wireless router has a port mirroring or port spanning feature, turn it on and point it at your workstation's IP. Use Wireshark on your workstation to look at the packets arriving on the interface assigned to that IP.
If your workstation has a wireless card, get Connectify for Windows 7 (turns wireless card into Wifi Hotspot). Connect iPhone through Windows 7 wireless, and workstation through ethernet to the internet. Your workstation will effectively act as a router for your iPhone and you will be able to record iPhone's packets passing through it.
Get an ethernet hub (make sure it is not a switch, you won't see all packets on every interface with a switch), and connect your workstation, wifi router and internet to it.
Get a switch with port mirroring feature, configure port mirroring to forward a copy of all packets to your workstation.
Another option that I wish someone would have mentioned to me is pfSense. This is an operating system based on BSD made to serve as a firewall. Top of the line routers have, say 400 Mhz of processing speed, and unimpressive amounts of ram. The lowest-end computer you'll find these days has better specs than that, and of course, it's upgradeable. You don't have to bother with those terrible Cisco licenses (no DHCP with no license, 20 DHCP users at one license level, 100 users at an higher lever? Ludicrous), etc. Best of all, you have "root' access to the system, so you can run whatever you want on it (including wireshark, say)!!
Make sure you have two sufficiently fast ethernet cards. You'll set your wireless router to not do NAT (because pfSense will be doing that), then you can get to work setting up your VPN server, etc. without thinking about cisco licensing, etc.