Resolution, of sorts
The client computer that was showing this problem had Trend Micro Security installed. This security suite placed a service or driver on top of each network adapter in the system. I did not bother to debug further once this legacy app started working again.
Update 1
I disabled TCP window scale auto-tuning on Win7.
On Windows 7 if I unplug the ethernet cable directly connected to the server, the disconnection happens after about 5 seconds but the client process crashes. netstat on the server reports two TCP connections to the client that are no longer valid, because the client process did not gracefully shutdown and close the connections.
After putting the server in this strange state after the physical disconnect, If I restart the client process it hangs while connecting to the server (just as described in the original)
If I perform a physical disconnection on the XP side, the disconnect happens more quickly than on Win7. Some sort of keep alive value or behavior is different on XP. While ssh'd (via Putty) the ssh connection dies more quickly on XP than Win7 as well.
Original
I have a legacy TCP client/server app that appears to foul up the server only when the client is a Windows 7 machine.
The server is OpenEmbedded Linux running 2.6.11.
A Windows 7 client connects for a bit, and eventually gets to a state where the client disconnects after a second or two.
Once the server is in this state, If I immediately connect a Windows XP client, the XP client cannot connect either.
I cannot appear to get the server into the buggy state by connecting with an XP client alone.
I'd like to know what changes were made to the TCP/IP stack starting with Vista or Windows 7 so I can better debug the legacy code.
I'd also like to know what commands I can run on the Linux server that might better help me understand why the connections are failing.
Perhaps the best thing you can do is to fire up tcpdump or wireshark under linux and analyze the TCP SYN sent by both Windows XP and Windows 7. Wireshark allows you to break out bit-by-bit what TCP options are sent... for example, this is what you see from a debian lenny box making a TCP connection:
Transmission Control Protocol, Src Port: 58456 (58456), Dst Port: 23 (23), Seq: 0, Len: 0
Source port: 58456 (58456)
Destination port: 23 (23)
Sequence number: 0 (relative sequence number)
Header length: 40 bytes
Flags: 0x02 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 5840
Checksum: 0x8b77 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (20 bytes)
Maximum segment size: 1460 bytes
SACK permitted
Timestamps: TSval 136991740, TSecr 0
NOP
Window scale: 6 (multiply by 64)
My suspicion is that you'll see differences in RFC 1323 Window Scaling, but I don't have an XP machine handy to validate this.
I gave a detailed response of how to analyze TCP connections using tcptrace under linux in this answer...
How can I measure the performance and TCP RTT of my server code?
I also suspect a Window Scaling issue. I cannot find a link just at the moment, but there were complaints when Vista first came out reporting that that something was screwing with some routers (belkins If I recall). They traced it down to a problem with one of the window sizes that Vista (and thereby Windows 7) changes by default. The routers would get hung up and need to be reset every few minutes.
You can issue some commands to turn off window scaling, see if your problem goes away.
From Here:
netsh interface tcp set global autotuninglevel=disabled
Edit:
Try disabling IPv6 on windows 7. Link on how to do that. With IPv4, it should act the same as windows XP. Load up wireshark on the two systems and compare the differences
Related
I am using ubuntu 20 and I am connected with wifi to the hotspot of a Galaxy A20e running android 12 which is receiving 4G. I have a connection problem that is not occuring when using my ADSL connection.
Test description : I opened a dozen of shells and established ssh connections to a dozen of servers and I just wait without interacting with the shells.
After some time (usually 5 to 10 minutes), I observe a "client_loop: send disconnect: Broken pipe ssh" message on some of the shells, then after a longer time, I observe the same message on some other shells, until after maybe one hour, all connections are gone.
Using wireshark, I have filtered on packets exchanged with one of the servers and I notice no packets exchanged except the "keep alive" signal that is send from my computer every 5 minutes, (which is conform to my ssh client configuration). At some point, in response to one of those signal, the server returns RST ACK which means that the connection has been interrupted.
I tried to find the root cause of the connection cut by using pings but I did not find anything special during the 5 minutes window when the connection cut happens. Only thing I noticed is that some pings are sometimes not received.
Any idea ?
Thanks
This question belongs to https://serverfault.com/
Try adding this to your .ssh/config:
Host *
ServerAliveInterval 60
ServerAliveCountMax 5
Most probably your 4G router or your 4G operator terminate idle connections.
I have a strange issue with Asterisk (in this case 13.2 version) and WebRTC.
So, I have latest Asterisk 13.2, latest Crome (with Firefox - same problem) and sip.js (also tried with sipml5) and local network - no nat or firewall.
The problem: if call is answered immediately - everything works fine. But if there are some delay in answer (say, 10 seconds) - no audio in both directions.
In RTP debug I saw that if there is some delay - destination ip address is incorrect. After removing ice servers from client config - both addresses is correct, but still no audio.
Below is debug for call with audio:
rtp http://pastebin.com/EzfByCG5
sip http://pastebin.com/1Y08yF5s
and no audio call (answered after 10 seconds delay):
rtp http://pastebin.com/TNnFkz6M
sip http://pastebin.com/zG7pjcZD
Also in FreeSwitch everything works fine, no matter when call is answered.
Starting with Asterisk 12 you need to have pjproject libraries installed, otherwise you most likely won't have audio in your WebRTC calls and no warning whatsoever!
First question: have you ensured all firewall configs permit RTP streams from the chosen STUN / ICE server unconditionally?
My own experience is that audio issues with WebRTC are almost always related to STUN / ICE & Firewall.
Did you follow a tutorial for your set up? If so, which one?
Check the log...
Peer audio RTP is at port 192.168.88.187:50026
sip_route_dump: route/path hop: sip:889#df7jal23ls0d.invalid;transport=ws
[Feb 13 06:15:59] ERROR[1055][C-00000031]: netsock2.c:303 ast_sockaddr_resolve: getaddrinfo("df7jal23ls0d.invalid", "(null)", ...): Name or service not known
[Feb 13 06:15:59] WARNING[1055][C-00000031]: chan_sip.c:16158 __set_address_from_contact: Invalid host name in Contact: (can't resolve in DNS) : 'df7jal23ls0d.invalid'
I would use Freeswitch, no doubt :-)
I made a tcp/ip echo server by using kqueue on a unix(OSX) machine.It desinged to open 100 tcp/ip ports and accept 4000 clients per port.I made about 230,000 connections by using 15 another machines. ( 4000 conn per single process, and 4 process per box)
It seems that the server could accept more than that but the problem was the client side.There is a limitation to make much connections. Such as Windows XP - 3000, Windows7 & Unix - 16384 ..
Is the limitation right ? did I wrong ? I want to make as much connections as I can on a single client, such as 500,000 / Machine.
How could I overcome ?
You can configure multiple IPv4 address on the client machine. Process that runs on client should receive source IP address as parameter, and bind connect socket to it. So with 10 IP addresses you can easily reach 400000 connections.
I want to make as much connections as I can on a single client, such as 500,000 / Machine.
You can't. A TCP connection is identified by the tuple {protocol, source address, source port, target address, target port}. Four of these five elements are fixed. The remaining element, source port, can only have 65535 distinct values at the most, as a port number has 16 bits and cannot be zero.
So your expectation of 500,000 connnections to the same client is over-optimistic by a factor of about 10.
I'm using Python 2.7, pySerial under windows 7.
I have 8 devices, they are connected to my PC via Virtual COM port (Silicon Labs CP210x USB to UART Bridge), I'm testing them With multiprocessing all 8 COM ports are open and each time i'm sending command to one unit only, there is no MultiThreading.
The problem is that after X time (it could be 10 minutes or 5 hours), the output Queue of the serial ports fails to send me responses. it's not a specific port each time it's a different port (it can be several ports)
It's importent to say, the device gets my command and do it. the fail is to get the response, The device i'm testing is OK for sure.
I am sniffing the port with Serial monitor, all the commands send OK and the device makes them, only it doesn't respond.
Any idea's ?
There could be n number of reasons:
Buffers might be full
Com Port is not working or might be
And finally the device is malfunctioning..
Check out these things might be it will help you.
We have problems when using a device on windows compact framework 2.0 (windows mobile) and a server with IIS (7) on windows server 2008 R2. We are on WIFI.
We encounter many problems of latency and freezing. Our app is pretty simple. It just send a very small request (a string of 10 chars) to the server which will respond with a string of the same length. There is a request from the device to the server every 3 or 4 seconds.
It works well for some times and suddenly it freeze. It does that with other clients environment : so the only things which vary is the network itself (not the device or the server they both were tested separately and together and they perform well on a wired network).
We are using TCP and we read that it does not work so well on WIFI where the packet loss are not always due to the same reason when on a wired network (congestion).
Does somebody had freezing problems like us on TCP over WIFI ? Do you think we pointed out the same problem as you (TCP over WIFI) ?
We would like to change the protocol used. The first thing we would like to try is TCP Westwood.
Is TCP Westwood not offered on windows server and windows mobile ? If yes, how do you activate it ?.
Our last solution is to build our own server and protocol using UDP. But it's a hard work.
Thank you for answering.
Try setting the TCP_NODELAY socket option as your sending small chunks less than 1500. This will improve performance in a lossy network.