[Solved]TCP connection blocked in SYN_SENT status

I set up openssh daemon on my host and try to ssh to localhost to ensure it working. However the connection blocked for minutes then get
ssh: connect to host localhost port 22: Connection timed out
I checked "netstat -antup" output, the daemon was started and the new connection was in SYN_SENT status before time out
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 1 127.0.0.1:38127 127.0.0.1:22 SYN_SENT -
I did not add any iptables rules on my host, here is the log of sysctl net.ipv4
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.ip_forward = 0
net.ipv4.ip_default_ttl = 64
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.ip_nonlocal_bind = 0
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 16384
net.ipv4.tcp_max_tw_buckets = 180000
net.ipv4.ipfrag_high_thresh = 262144
net.ipv4.ipfrag_low_thresh = 196608
net.ipv4.ip_dynaddr = 0
net.ipv4.ipfrag_time = 30
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_stdurg = 0
net.ipv4.tcp_rfc1337 = 0
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.ip_local_port_range = 32768 61000
net.ipv4.icmp_echo_ignore_all = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.icmp_errors_use_inbound_ifaddr = 0
error: permission denied on key 'net.ipv4.route.flush'
net.ipv4.route.min_delay = 2
net.ipv4.route.max_delay = 10
net.ipv4.route.gc_thresh = 4096
net.ipv4.route.max_size = 65536
net.ipv4.route.gc_min_interval = 0
net.ipv4.route.gc_min_interval_ms = 500
net.ipv4.route.gc_timeout = 300
net.ipv4.route.gc_interval = 60
net.ipv4.route.redirect_load = 5
net.ipv4.route.redirect_number = 9
net.ipv4.route.redirect_silence = 5120
net.ipv4.route.error_cost = 250
net.ipv4.route.error_burst = 1250
net.ipv4.route.gc_elasticity = 8
net.ipv4.route.mtu_expires = 600
net.ipv4.route.min_pmtu = 552
net.ipv4.route.min_adv_mss = 256
net.ipv4.route.secret_interval = 600
net.ipv4.igmp_max_memberships = 20
net.ipv4.igmp_max_msf = 10
net.ipv4.inet_peer_threshold = 65664
net.ipv4.inet_peer_minttl = 120
net.ipv4.inet_peer_maxttl = 600
net.ipv4.inet_peer_gc_mintime = 10
net.ipv4.inet_peer_gc_maxtime = 120
net.ipv4.tcp_orphan_retries = 0
net.ipv4.tcp_fack = 1
net.ipv4.tcp_reordering = 3
net.ipv4.tcp_ecn = 0
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_mem = 47808 63744 95616
net.ipv4.tcp_wmem = 4096 16384 2039808
net.ipv4.tcp_rmem = 4096 87380 2039808
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_adv_win_scale = 2
net.ipv4.icmp_ratelimit = 250
net.ipv4.icmp_ratemask = 6168
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_frto = 0
net.ipv4.tcp_low_latency = 0
net.ipv4.ipfrag_secret_interval = 600
net.ipv4.ipfrag_max_dist = 64
net.ipv4.tcp_no_metrics_save = 0
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_tso_win_divisor = 3
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_abc = 0
net.ipv4.tcp_mtu_probing = 0
net.ipv4.tcp_base_mss = 512
net.ipv4.tcp_workaround_signed_windows = 0
net.ipv4.tcp_dma_copybreak = 4096
net.ipv4.tcp_slow_start_after_idle = 1
net.ipv4.cipso_cache_enable = 1
net.ipv4.cipso_cache_bucket_size = 10
net.ipv4.cipso_rbm_optfmt = 0
net.ipv4.cipso_rbm_strictvalid = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.neigh.default.mcast_solicit = 3
net.ipv4.neigh.default.ucast_solicit = 3
net.ipv4.neigh.default.app_solicit = 0
net.ipv4.neigh.default.retrans_time = 100
net.ipv4.neigh.default.base_reachable_time = 30
net.ipv4.neigh.default.delay_first_probe_time = 5
net.ipv4.neigh.default.gc_stale_time = 60
net.ipv4.neigh.default.unres_qlen = 3
net.ipv4.neigh.default.proxy_qlen = 64
net.ipv4.neigh.default.anycast_delay = 100
net.ipv4.neigh.default.proxy_delay = 80
net.ipv4.neigh.default.locktime = 100
net.ipv4.neigh.default.gc_interval = 30
net.ipv4.neigh.default.gc_thresh1 = 128
net.ipv4.neigh.default.gc_thresh2 = 512
net.ipv4.neigh.default.gc_thresh3 = 1024
net.ipv4.neigh.default.retrans_time_ms = 1000
net.ipv4.neigh.default.base_reachable_time_ms = 30000
net.ipv4.neigh.lo.mcast_solicit = 3
net.ipv4.neigh.lo.ucast_solicit = 3
net.ipv4.neigh.lo.app_solicit = 0
net.ipv4.neigh.lo.retrans_time = 100
net.ipv4.neigh.lo.base_reachable_time = 30
net.ipv4.neigh.lo.delay_first_probe_time = 5
net.ipv4.neigh.lo.gc_stale_time = 60
net.ipv4.neigh.lo.unres_qlen = 3
net.ipv4.neigh.lo.proxy_qlen = 64
net.ipv4.neigh.lo.anycast_delay = 100
net.ipv4.neigh.lo.proxy_delay = 80
net.ipv4.neigh.lo.locktime = 100
net.ipv4.neigh.lo.retrans_time_ms = 1000
net.ipv4.neigh.lo.base_reachable_time_ms = 30000
net.ipv4.neigh.eth0.mcast_solicit = 3
net.ipv4.neigh.eth0.ucast_solicit = 3
net.ipv4.neigh.eth0.app_solicit = 0
net.ipv4.neigh.eth0.retrans_time = 100
net.ipv4.neigh.eth0.base_reachable_time = 30
net.ipv4.neigh.eth0.delay_first_probe_time = 5
net.ipv4.neigh.eth0.gc_stale_time = 60
net.ipv4.neigh.eth0.unres_qlen = 3
net.ipv4.neigh.eth0.proxy_qlen = 64
net.ipv4.neigh.eth0.anycast_delay = 100
net.ipv4.neigh.eth0.proxy_delay = 80
net.ipv4.neigh.eth0.locktime = 100
net.ipv4.neigh.eth0.retrans_time_ms = 1000
net.ipv4.neigh.eth0.base_reachable_time_ms = 30000
net.ipv4.neigh.wlan0.mcast_solicit = 3
net.ipv4.neigh.wlan0.ucast_solicit = 3
net.ipv4.neigh.wlan0.app_solicit = 0
net.ipv4.neigh.wlan0.retrans_time = 100
net.ipv4.neigh.wlan0.base_reachable_time = 30
net.ipv4.neigh.wlan0.delay_first_probe_time = 5
net.ipv4.neigh.wlan0.gc_stale_time = 60
net.ipv4.neigh.wlan0.unres_qlen = 3
net.ipv4.neigh.wlan0.proxy_qlen = 64
net.ipv4.neigh.wlan0.anycast_delay = 100
net.ipv4.neigh.wlan0.proxy_delay = 80
net.ipv4.neigh.wlan0.locktime = 100
net.ipv4.neigh.wlan0.retrans_time_ms = 1000
net.ipv4.neigh.wlan0.base_reachable_time_ms = 30000
net.ipv4.conf.all.forwarding = 0
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.all.accept_redirects = 1
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.shared_media = 1
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.all.send_redirects = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.all.medium_id = 0
net.ipv4.conf.all.bootp_relay = 0
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.all.tag = 0
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.all.arp_accept = 0
net.ipv4.conf.all.disable_xfrm = 0
net.ipv4.conf.all.disable_policy = 0
net.ipv4.conf.all.force_igmp_version = 0
net.ipv4.conf.all.promote_secondaries = 0
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.default.accept_redirects = 1
net.ipv4.conf.default.secure_redirects = 1
net.ipv4.conf.default.shared_media = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.default.accept_source_route = 1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.medium_id = 0
net.ipv4.conf.default.bootp_relay = 0
net.ipv4.conf.default.log_martians = 0
net.ipv4.conf.default.tag = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.arp_announce = 0
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.default.arp_accept = 0
net.ipv4.conf.default.disable_xfrm = 0
net.ipv4.conf.default.disable_policy = 0
net.ipv4.conf.default.force_igmp_version = 0
net.ipv4.conf.default.promote_secondaries = 0
net.ipv4.conf.lo.forwarding = 0
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.lo.accept_redirects = 1
net.ipv4.conf.lo.secure_redirects = 1
net.ipv4.conf.lo.shared_media = 1
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.lo.send_redirects = 1
net.ipv4.conf.lo.accept_source_route = 1
net.ipv4.conf.lo.proxy_arp = 0
net.ipv4.conf.lo.medium_id = 0
net.ipv4.conf.lo.bootp_relay = 0
net.ipv4.conf.lo.log_martians = 0
net.ipv4.conf.lo.tag = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.arp_announce = 0
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.lo.arp_accept = 0
net.ipv4.conf.lo.disable_xfrm = 1
net.ipv4.conf.lo.disable_policy = 1
net.ipv4.conf.lo.force_igmp_version = 0
net.ipv4.conf.lo.promote_secondaries = 0
net.ipv4.conf.eth0.forwarding = 0
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.eth0.accept_redirects = 1
net.ipv4.conf.eth0.secure_redirects = 1
net.ipv4.conf.eth0.shared_media = 1
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth0.send_redirects = 1
net.ipv4.conf.eth0.accept_source_route = 1
net.ipv4.conf.eth0.proxy_arp = 0
net.ipv4.conf.eth0.medium_id = 0
net.ipv4.conf.eth0.bootp_relay = 0
net.ipv4.conf.eth0.log_martians = 0
net.ipv4.conf.eth0.tag = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.arp_announce = 0
net.ipv4.conf.eth0.arp_ignore = 0
net.ipv4.conf.eth0.arp_accept = 0
net.ipv4.conf.eth0.disable_xfrm = 0
net.ipv4.conf.eth0.disable_policy = 0
net.ipv4.conf.eth0.force_igmp_version = 0
net.ipv4.conf.eth0.promote_secondaries = 0
net.ipv4.conf.wlan0.forwarding = 0
net.ipv4.conf.wlan0.mc_forwarding = 0
net.ipv4.conf.wlan0.accept_redirects = 1
net.ipv4.conf.wlan0.secure_redirects = 1
net.ipv4.conf.wlan0.shared_media = 1
net.ipv4.conf.wlan0.rp_filter = 0
net.ipv4.conf.wlan0.send_redirects = 1
net.ipv4.conf.wlan0.accept_source_route = 1
net.ipv4.conf.wlan0.proxy_arp = 0
net.ipv4.conf.wlan0.medium_id = 0
net.ipv4.conf.wlan0.bootp_relay = 0
net.ipv4.conf.wlan0.log_martians = 0
net.ipv4.conf.wlan0.tag = 0
net.ipv4.conf.wlan0.arp_filter = 0
net.ipv4.conf.wlan0.arp_announce = 0
net.ipv4.conf.wlan0.arp_ignore = 0
net.ipv4.conf.wlan0.arp_accept = 0
net.ipv4.conf.wlan0.disable_xfrm = 0
net.ipv4.conf.wlan0.disable_policy = 0
net.ipv4.conf.wlan0.force_igmp_version = 0
net.ipv4.conf.wlan0.promote_secondaries = 0
I wrote another easy socket program by myself, strace it and find that the program blocked in the "accept" system call. How can I solve this problem, or what can I do to find out more clues? Thanks very much.
Last edited by henryouly (2007-06-16 12:17:34)

Lucke most likely nailed it. FWIW, all SYN_SENT means is that you weren't sent an RST and the SYN attempt silently failed for whatever reason. You can create the exact same state by sshing to a host that either doesn't exist on your network or is down. Probably if you were sniffing traffic on your network, what you'd see is several ARPs coming from your machine, and no answers, or an ARP request, and ARP reply, and then a SYN packet with no reply. In any case, it's most likely wrappers blocking access to the port.
Last edited by Snarkout (2007-06-08 14:32:02)

Similar Messages

Anyone else having an issue with TCP connections using iCloud for Windows?

Hi,
Before I asked this question, I did wait to see if any related questions came up, but none did, so I submit it now.
On my admittedly older laptop running Windows 7 64b Home, I've run into difficulties with the iCloud for Windows app to the extent that I had to uninstall it.
It would that, as my laptop was running, in the background, iCloudServices.exe would endlessly iterate TCP connections, which, while not actively sending or receiving any data, after some hours would number over 100 instances, taking up resources, and grinding my laptop's WiFi connection to a grindingly slow pace. I ended up, within the app, turning off everything, iCloud Drive and Photos, (I never used bookmarks), but still this would continue to occur.
I contacted Apple Support, explaining what was going on, and they stated they only dealt with IOS and gave me a Microsoft Support number. When I called Microsoft support, I came more and more to the realization that the issue was specifically with the iCloud for Windows app, as that was the only software that was endlessly creating and not closing TCP connections as it was. How was Microsoft supposed to solve an issue with Apple code?
So I called Apple back, whereupon they insisted it was a Microsoft issue. I explained other cloud services installed on the same computer were not having the same issue, it was unique to ICloudServices.exe. They stated they only dealt with IOS. I stated I purchased an iPad Air less than 7 months ago, and was trying to run iCloud in support of that. They again stated they only dealt with IOS, and suggested I again try Microsoft. I asked them if it was reasonable to expect Microsoft to solve issues with Apple code? They said regardless, there was zero support offered for anything having to do with Windows, and all I could do was uninstall the app, which I did, though that did not feel very satisfactory to me. My thinking is, if Apple writes a Windows app in support of their hardware, they should offer support for it.
Anyway, I was just wondering, is this an issue unique to me? or have others experienced a similar issue? I found this issue by opening the Windows Resource Monitor, looking under the Networking tab, and scrolling through the TCP Connections section to find 100+ concurrent iCloudServices.exe instances listed, whereas even Chrome, with multiple tabs and extensions, topped out at around 20.
My one month old Desktop, DYI, sports a solid Asus 1150 MoBo, i7-4790k cpu, 16GB Ram, and an EVGA GTX 970 video card. I list some specs only to illustrate this computer has no hardware issues in comparison to my long in tooth laptop. On this desktop, running Win 8.1 Pro 64b, at least as many, identifiably Apple, background service TCP connections are created even compared to Chrome, regardless of many tabs being open, many extensions, and even some related apps. Adobe does not even come close, though I run the full CC subscription. On this new computer, running Windows 8.1 Pro 64b, there are currently over 50 TCP connections and loopbacks that do not identify themselves, with just a - for the Image, and PID. With the experience on my laptop, I wonder how many of these are generated by Apple software, if not specifically iCloud software?
The frustrating aspect of these connections is they seem in no way active, While the Chrome and Adobe connections can be seen to be transferring data, as long as I am not running iTunes, or so have my iPad actually plugged in, it seems 99% of the time these iCloudServices.exe connections are just taking up ports, neither sending nor receiving any data discernable to me under the Processes with Network Activity, or Network Activity lists, both displayed in the same window as the TCP Connections in the Windows Resource Monitor.
Though I am fairly ignorant as regards coding, it seems as if there is no call to close a connection, very specifically, iCloudServices.exe, when it is no longer needed, and the next time a connection is needed, a new one is opened, rather than accessing the one previously opened. The only other reason I could imagine this might be occurring is if my Norton Internet Security software might mask and/or block the port after a certain time of inactivity.
Anyone out there have any ideas or advice about this? Thanks in advance.

Thanks jared,
I'm still dealing with this issue through Apple. Some time after I posted this, I contacted Apple again. They did start a case up for me, as I was experiencing the same behavior on two different machines, with two different versions of Windows.
So far it remains unsolved. I've logged iClouds for Windows on my desktop, which is brand new, then logged for awhile after completely uninstalling Norton Security Suite, depending on the Microsoft security for some time, and finally logged after I uninstalled iCloud for Windows, restarted, installed a clean download, and connected using a completely different test account, which Apple set up for me. None of this made any difference. Looking at the logs, it seems every 10 minutes, iCloudServices.exe creates a new TCP connection to confirm I'm using less than 5GB on iCloud, (which I am by a good margin, using less than 2GB), it seems this connection is not closed, and when the next iteration rolls around 10 minutes later, a new TCP connection is created. I come very close to having 6 TCP connections created per hour, until I restart my computer. This works out to... 6 x 24 = 144/day.
Perhaps the article you posted will shed some further light on this. I'm thinking seeing the state of the connection through netstats, at the least, could help.
For the last week, I've been putting a hold on further logging, as Apple wants me to create a new user account on one of my computers, install iCloud for Windows there, and log it running in the other account. This however basically means I cannot use my computer for a fair number of hours, and I've been busy enough with work the past week that I haven't the time or energy to afford to set this up and run it. I've had need of my computers too much for the past week.

TCP connection error when sending MODBUS commands to WAGO 750-881 controller after 113655 bytes of data have been sent

Hi all,
I am new to the world of labview and am attempting to build a VI which sends commands to a 750-881 WAGO controller at periodic intervals of 10ms.
To set each of the DO's of the WAGO at once I therefore attempt to send the Modbus fc15 command every 10ms using the standard Labview TCP write module.
When I run the VI it works for about a minute before I recieve an Error 56 message telling me the TCP connection has timed out. Thinking this strange, I decided to record the number of bytes sent via the TCP connection whilst running the program. In doing so I noticed that the connection broke after exactly 113655 Bytes of data had been sent each time.
Thinking that I may have been sending too many messages I increased the While-loop delay from 10ms to 20, 100 and 200 ms but the error remained. I also tried playing with the TCP connection timeout and the TCP write timeout but neither of these had any effect on the problem.
I cannot see why this error is occuring, as the program works perfectly up untill the 113655 Bytes mark.
I have attached a screenshot of the basic VI (simply showing a MODBUS command being sent every second) and of a more advanced VI (where I am able to control each DO of the WAGO manually by setting a frequency at which the DO should switch between ON and OFF).
If anybody has any ideas on where the problems lie, or what I could do to further debug the program this would be greatly appreciated.
Solved!
Go to Solution.
Attachments:
Basic_VI.png ‏84 KB
Expanded_VI.png ‏89 KB

AvdLinden wrote:
Hi ThiCop,
Yes the error occurs after exactly 113655 bytes every time. The timeout control I would like to use is 10ms, however even increasing this to 1s or 10s does not remove the error, which leads me to believe that this is not the issue (furthermore, not adding any delay to the while loop, thus letting it run at maximum speed, has shown that the TCP connection is able to send all 113655 bytes in under 3 seconds again pointing towards the timeout control not being the issue here).
I attempted Marco's suggestion but an having difficulty translating the string returned into a readable string, (rightnow the response given is " -# + ").
As to your second suggestion, I implemented something similar where I created a sub VI to build a TCP connection, send a message and then close the connection. I now build each message and then send the string to this subVI which successfully sends the command to my application. Whilst not being the most elegant method of solving the issue, it has resolved the timeout problem meaning I am able to send as many commands as I want. So in that sense the problem has been solved.
If you still have tips on how to correctly read the TCP read output, I would however like to see if I could not get my first program to work as it is slightly more robust in terms of timing.
Modbus TCP RTU is a binary protocol, as you show in your Basic VI, where you format the data stream using byte values. So you have to interprete the returned answer accordingly with the Modbus RTU spec in hand. Now what is most likely happening is that the connection gets hung after a while since you do NOT read the data the device sends as response to your commands. The TCP/IP stack buffers those bytes and at some point the internal buffers overflow and the connection is blocked by the stack. So adding the TCP Read at strategic places (usually after each write) is the proper solution for this. Is there any reason that you didn't use the NI provided Modbus TCP library?
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Router closes TCP connection after 30 minutes

I have recently replaced my D-Link DIR-100 router with a Cisco Linksys RV042, but unfortunately there seems to be a problem with it.
I have an external TCP connection coming in to a local service, and I therefore set up the router to redirect the incoming connection for the given port to the local PC hosting the service. This worked perfectly. I also opened the Firewall access rules to allow all data from WAN2 to be propagated through. This also worked just fine, and I can connect from the internet to the local PC, just like I could with my old router. Unfortunately this is where the simularities stop. When there is no communication on the TCP connection for more than 30 minutes then the router closes the connection automatically. This is NOT what I want. I only communicate on the TCP connection very rarely, but I do not want it closed automatically - at least not after just 30 minutes.
I did some research on line and it appears that there in some routers are a TCP connection timeout, which in the router I read about, defaulted to 1 day. This would be OK. I experimented and found that if there is communication every 30 minutes then it is not close the connection, but if there is 50minutes between communication then it closes the connection.
As I read that this timeout has to do with security I experimented with the firewall and found the following:
1. Disabling the entire router firewall fixes the problem !!!
2. Disabling just DoS has no effect (problem still exists)
3. Disabling SPI means I cannot connect at all !!! (new and much worse problem)
4. Disabling Block WAN Requests has no effect (problem still exists)
Is there a way to solve this problem without disabling the entire firewall, as that is not what I want to do. I have the system set up for Dual WAN (load balancing), and I only want to allow connections to a handful of ports on the one WAN, and block the other WAN entirely.
P.S. I was referred to the Cisco Small Business Support Community by the Cisco Home community, so I hope this is the right place.

Hi Ddb101,
This is a limitation (or feature depending on how you look at it) of the iPhone/iPod touch. 30 minutes after the device locks (usually 5 minutes of inactivity) the network turns off completely to save battery life. You can either turn autolock off globally, or some programs (mine for instance see: http://ootunes.com/app/ ) have an option that disables sleep while the app is running so the stream will keep playing... until your battery dies Only problem is with the screen on the battery actually dies even faster!
Finally, if the device is connected to a constant power source, it shouldn't actually time out. So if you have a way to plug it in, it shouldn't quit after 30 minutes on you...
hope that helps,
also, since there's a link to my site up there, and I sell the app, I should tell you that I might get money if you go to the page and end up buying my app...

How to prevent a TCP connection being closed when the VI that opened it finishes.

Hello everyone.
I am developing an application based around servers and clients communicating over TCP in LabVIEW 2012.
When the server/client opens a TCP connection ,it launches an asynchronosly running "connection handler", to which it passes the connection reference which then takes over all the communcation. This all works fine.
However - I have a situation where a client's connection handler can be informed of another "new" server. I would like it to open the connection (to see if it is still valid) and then pass this connection reference back to the client's main code to spawn a new connection handler. This prevents me locking up the Client's main code with a long-ish timeout if the "new" server is not actually accepting connections.
The issue is that if the connection handler that opened up the connection to the "new" server is stopped, then it appears to destroy the reference that it opened. This means that the other connection handler that was merrily communcating with the "new" server has its TCP communciations closed (I get an Error code 1 on a write).
I have created an example to demonstrate the issue which should be used as follows:
1. Run server.vi - it will listen for a connection on the port specifed on its BD.
2. Run CH Launcher.vi - it will open a connection to the server and pass the TCP reference to an instance of Connection Handler.vi which it launches.
3. The Connection Handler should send data to the Server
4. Stop the CH Launcher.vi
5. The Connection Handler.vi will error.
Any suggestions would be much appreciated.
Cheers
John
Solved!
Go to Solution.
Attachments:
TCP Test.zip ‏35 KB

John_Neutron escreveu:
In my case I have changes the part of the code that opens the TCP connection to a VI that has the same lifetime as the main VI so that any connections that have been opened will only be closed automatically when the main VI stops.
And what are the effects? You are still facing the same problem or closing the connection only when the whole applicaton stops solved your problem?
Regards
Mondoni

Wired port cannot establish TCP connections

I have come across an error that I have so far been unable to solve via google/searching forums.
From time to time, the wired port loses the capability to establish TCP connections. I can ping fine, I can resolve names fine indicating that at least UDP 53 is working. It's impossible to complete a three way handshake for any TCP connection, be it SSH, HTTP, FTP or anything else. This happens randomly after a network connection has been working fine for days. The Internet Connection Wizard claims everything is peachy as it probably just performs a ping to some site.
A reboot does not fix the problem - what does fix it is unplugging the cable, changing to wireless and associating with a network, opening a connection, then shutting down AirPort again and plugging the cable back in. Just replugging without establishing a TCP connection via AirPort does not work.
Is there anything I am missing here? Should I be contacting an Apple Store to talk about repairs/replacements?
Thanks for your time and consideration, if there's any other information needed to make light of the problem, I will post it as soon as I see the request. Unfortunately, I cannot produce the problem at will and have so far neglected running a traffic sniffer to look at exactly what is happening on a packet level - tho "telnet server 80" times out when "ping server" works fine.

Well, I have gotten the FMS on Windows to work via my basic client app (via localhost in the NetConnection call). Taking the same SWF and specifying the external IP of the Windows machine doesnt work.
So I am kind of back to square one.
I made sure that the default Adaptor is bound to any IP (using ":1935,80" in the default Adaptor.xml HostPort tag). So FMS should be bound to all network interfaces.
Just to clarify: FMS is running in "development" mode. Does that mode prevent external connections?

SSL connections blocking worker threads on DS 5.2 patch 4

Hi,
Is it normal for an idle SSL connection to consume a worker thread within the directory server?
We have recently enabled SSL on a number of our directory servers (5.2 patch 4) and have run into problems with the server hanging. We have a number of application servers, each opening a pool of connections to the servers via JNDI. It seems that once 30 SSL connections have been established to a give LDAP server, the server will hang. By hang I mean the server is accepting TCP connections, but not responding to LDAP requests.
The server can deal with a lot more than 30 non-ssl connections. I'm guessing that SSL connections need to maintain state, which is what is tying up the worker threads.
Is this normal, and is it docuemented anywhere? Currently I'm looking at terminating the SSL connections on a load balancer in front of the LDAP servers, or perhaps on an LDAP proxy. Any other suggestions as to how this is typically dealt with?
thanks,
R

Thank you Gautam.
On further testing yesterday, we discovered that the problem is just as you have described. Our application servers are opening an initial pool of five connections, but typically only using one of those connections. The one connection the server uses to make an LDAP request behaves 'normally', not tying up a thread on the LDAP server. The other four sit there blocking a thread each, until eventually we hit the nsslapd-threadnumber.
Based on that discovery, we're having the application changed so that its initial LDAP connection pool size is one, which appears to address the problem. That way connections are only established and added to the pool as they are required, resulting in well behaved connections to the LDAP server.
Thanks for the quick reply... The Sunsolve note is helpful, as is the info about the nsslapd-ioblocktimeout parameter.
kind regards,
R

TCP connection for DHCP failover frequently are broken in Solaris 10

Hi
We have two dhcp servers which are installed in Solaris 10 and set to a failover pair. Currently, we can find that tcp connection for dhcp failover protocol are frequently broken. It looks like that primary dhcp server initiatively send FIN message to secondary one but in general, this tcp connection should always keep alive. On the other hand, the tcp connection can not completely be closed right now which FIN_WAIT_2 status in Primary one and CLOSE_WAIT status in secondary would last for a long time.
Will Solaris 10 cause this fault? Is it a known bug in OS?
OS info:
-bash-3.00$ cat /etc/release
Solaris 10 5/08 s10s_u5wos_10 SPARC
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 24 March 2008
-bash-3.00$
-bash-3.00$
-bash-3.00$ uname -a
SunOS edns1 5.10 Generic_142900-03 sun4v sparc SUNW,Netra-T5220
TCP connection info:
Primary DHCP Server:
2012 08 29 03:41:43
PING 172.25.6.137: 56 data bytes 64 bytes from edns2 (172.25.6.137): icmp_seq=0. time=0.678 ms
remote refid st t when poll reach delay offset disp
==============================================================================
*idns1           195.26.151.151   3 u   45 1024 377     0.75   -0.071    0.05
+idns2           195.26.151.151   3 u 162 1024 377     0.93    0.169    0.08
clusternode1-pr 0.0.0.0 16 - - 1024 0 0.00 0.000 16000.0
+clusternode2-pr idns1            4 u 406 1024 376     0.49   -0.154   15.12
172.25.6.133.647 172.25.6.137.58107 49640 0 49640 0 ESTABLISHED
172.25.6.133.647 *.* 0 0 49152 0 LISTEN
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2012 08 29 03:41:47
PING 172.25.6.137: 56 data bytes 64 bytes from edns2 (172.25.6.137): icmp_seq=0. time=0.535 ms
remote refid st t when poll reach delay offset disp
==============================================================================
*idns1           195.26.151.151   3 u   49 1024 377     0.75   -0.071    0.05
+idns2           195.26.151.151   3 u 166 1024 377     0.93    0.169    0.08
clusternode1-pr 0.0.0.0 16 - - 1024 0 0.00 0.000 16000.0
+clusternode2-pr idns1            4 u 410 1024 376     0.49   -0.154   15.12
172.25.6.133.647 172.25.6.137.58107 49640 0 49640 0 FIN_WAIT_2
172.25.6.133.647 *.* 0 0 49152 0 LISTEN
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Secondary DHCP Server:
2012 08 29 03:41:41
PING 172.25.6.133: 56 data bytes 64 bytes from edns1 (172.25.6.133): icmp_seq=0. time=1.26 ms
remote refid st t when poll reach delay offset disp
==============================================================================
*idns1           195.26.151.151   3 u 450 1024 377     0.92   -0.067    0.06
+idns2           195.26.151.151   3 u 552 1024 377     0.96    0.237    0.08
+clusternode1-pr idns1            4 u 360 1024 377     1.85   -0.528    1.51
clusternode2-pr 0.0.0.0 16 - - 1024 0 0.00 0.000 16000.0
172.25.6.137.647 *.* 0 0 49152 0 LISTEN
172.25.6.137.58107 172.25.6.133.647 49640 0 49640 0 ESTABLISHED
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2012 08 29 03:41:45
PING 172.25.6.133: 56 data bytes 64 bytes from edns1 (172.25.6.133): icmp_seq=0. time=1.36 ms
remote refid st t when poll reach delay offset disp
==============================================================================
*idns1           195.26.151.151   3 u 454 1024 377     0.92   -0.067    0.06
+idns2           195.26.151.151   3 u 556 1024 377     0.96    0.237    0.08
+clusternode1-pr idns1            4 u 364 1024 377     1.85   -0.528    1.51
clusternode2-pr 0.0.0.0 16 - - 1024 0 0.00 0.000 16000.0
172.25.6.137.647 *.* 0 0 49152 0 LISTEN
172.25.6.137.58107 172.25.6.133.647 49640 0 49640 0 CLOSE_WAIT
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Thanks!

Thanks, but had found a previous discussion with this hint and applied it.
svccfg -s sendmail listprop shows config /local_only = false
Yes, I would really love to fix the fault, but what I would really like is some hints as to how to debug ports under svc control.

2 way TCP connection using IP addresses

Hi All,
I need to pass data in both directions between 2 pc's connected to the internet. I am aware of the various TCP/IP and data socket examples, I am using Labview 7.0. I dont know much about the ptotocol involved but figure I only need a few pieces of info.
If the server machine wants to connect to a client machine on the same network I understand no changes are required to the example vis (ie port 2055 used in Simple Data Server). But what would happen if the server PC wanted to connect to a client in a different country? Is that when IP addresses are needed?
I imagine my final vi front panel will have a "This machines IP Addr" and "Client's IP Addr" text box, operators of the machines then tell the other person their mac
hine IP address which is entered manually to setup a 2 way link.
Is it possible to get Labview to find the full IP address of the machine ready for the other user to type in. Thanks in advance
Regards Chris

On the client side the users will need to fill in the IP address or domain of the server. If that IP is on the Internet or somewhere else that will work as long as the client PC has physical access and permission to open a tcp connection (no firewalls that block the port you are using etc.)
Make a connect dialog that pops up if the user chooses to connect and have the user input the IP there and click OK. You can add functionality like bookmarks and "home page" to make things easier. If a home page / server is defined the client can connect to that upon startup. You may want also to add functionality that will reconnect in the background if the connection is lost.
The client's IP is of less interest. If you need it though just use the string to IP function
and the IP to string function from the tcp/ip palette. Do not wire anything to the former funtion but wire it's output to the latter. The latter will then output the IP of the local PC.
MTO

Still looking for anwers to TCP Connection data

Can flash monitor TCP connection status? I need to read it
somehow and then send that info back to the server. Posted this a
number of weeks ago, but not a single nibble.
Anyone?

The server only uses port 80 in this case, and we are not
connecting to any other domains. He can't seem to get a policy file
to work, so the whole thing has now become my fault.
The deal is, using the .close(); method works fine, but his
PHP is pushing the file anyway. It took me a week to discover that
this issue isn't mine. But .. the php developer is convinced that I
haven't written the AS properly, or we wouldn't have this issue. I
simply state that the way I am using the .close() method works
fine, but his code is overriding it, which is out of my hands. But
I am trying to find a solution, and we are both thinking this
socket connection may be it, we just can't get it to work without
errors.
Funny, he pointed me to a site that he says does exactly what
he wants this to do, and it throws at least six errors before the
song finally plays. He has not acknowledge that minor deatil yet.
:)

TCP Connect Timeout

Does anyone know of a way to increase the TCP connection timeout on Linux (RedHat ES 3.0, 2.4.21-9.0.3.ELsmp). We currently always keep a "dead" server in our imqAddressList for failover. The server has nothing listening on the portmapper port, 7676. When I telnet over regular Internet it takes less than a second to get a connection refused response:
telnet: Unable to connect to remote host: Connection refusedWhen I telnet to this server over a low bandwidth satellite connection, I get a timeout after 3 minutes:
[root@client# time telnet server 7676
Trying X.X.X.X...
telnet: connect to address X.X.X.X: Connection timed out
real    3m15.393s
user    0m0.010s
sys     0m0.000sWe currently have 3 servers in our imqAddressList and imqReconnectAttempts is set to 0. However, since one of the 3 servers is dead, 1/3 of the time it takes over 3 minutes to get a connection. I'd imagine that the socket connection from IMQ is exhibiting the same behavior as telnet.
Is there anywhere that I can tweak this timeout?
Thanks,
Aaron

You need to call connect on a socket set to non-blocking mode with fcntl, and then use select with a timeout to limit the amount of time you will wait for the connect to complete. If select returns because you timed out, then close the socket and return an error. If select returns because of an event on the socket, you use getsockopt to determine if the connect succeeded or not.
See Stevens, Unix Network Programming Vol 1 for details. Comments in the code I'm looking at say page 411.
Hope this helps.

Proper method to reset tcp connection after timeout error

I have a application that I am building that communicates with a Modbus TCP device. If a communications error occurs I would like to be able the reset the TCP communications. What I have is a control that fires a event when pushed. In this event I have a sequence that first closes the tcp connection and then opens a new connection. My applications starts and runs fine. To test the reset function I removed the ethernet cable from the device and waited of a timeout to occur. I plugged the cable back in and pushed my reset control. Occasionally the reset will occur but most times I will get a time out error at the Open TCP vi. After this, the only way I can establish communications is to exit my application, disable and then enable my network device. Then when I restart my application I have communications with my device.
Any help would be appreciated on how I should be resetting my TCP connection.
Thanks
Terry
Solved!
Go to Solution.

Terry S wrote:
I have attached a example vi (LV10) that shows just the TCP connection and Reset. An error will occur when trying to perform the open tcp in the reset event.
As written your code should be fine. There is nothing inherently wrong with it. However depending on the device you are communicating with you may be trying to reestablish the connection too quickly after you closed the connection. The device may not allow multiple connections to it and may require sometime to clean things up on its end after you close a connection. As an experiment trying waiting a short time between the TCP Close and the TCP Open. If possible you may want to try using Wireshark to see what is happening on the network. It can be useful in diagnosing what is going on.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

How to get the IP of the client when TCP connect in the server

How to get the IP of the client when TCP connect in the server.
The only parameter got from the connection is connectionID.
Solved!
Go to Solution.

I guess you're using "TCP Wait on Listener" on the server. This returns the remote address and port (as optional outputs).

How to pass TCP connection ID into subpanel VI

Hi,
I am trying to pass a TCP connection ID into a subpanel VI, but wasn't successful.
Here's the function I used:
I was able to pass other control values into the VI but not the TCP conn ID.
Is there any restrictions or other ways I should do it?
Best regards,
Ken
Solved!
Go to Solution.

Hi Ken,
Is 'reference' a TCP connection ID? If so, wire the reference directly to the Ctrl Val.Set invoke node. No value property of the reference needed.
It definitely works with TCP connection IDs.
Hope this helps,
Daniel
Message Edited by dan_u on 02-20-2010 01:17 AM

Is something intercepting my TCP connections?

I have BT Infinite and have been testing my network latency using Ping for ICMP RTT, and NPing to measure TCP SYN/ACK RTT and UDP RTT.
I have found that my TCP connect latency, i.e. time create a TCP connection to a remote host, is always about 10ms, even when the ping is much higher. For example my ICMP ping to the time server 0.uk.pool.ntp.org (192.238.80.20) is about 160ms, but my TCP ping is about 10ms. I get the same result for almost any server on the internet anywhere in the world on any port, the TCP ping varies between 3ms and 12ms.
This implies that something local to my internet connection is intercepting my TCP connections, responding to my TCP connection requests and forwarding on the request to the remote host, e.g. a TCP proxy server, or firewall. The ping and TCP connection time to my broadband router is 1ms or under so its not my equipment. So I assume BT have some device on my connection path.
Has anyone experienced similar issues or knows what is causing this? Is it Parental Control network filters - I thought these worked by blocking DNS requests not by proxying and filtering traffic?

I have BT Infinite and have been testing my network latency using Ping for ICMP RTT, and NPing to measure TCP SYN/ACK RTT and UDP RTT.
I have found that my TCP connect latency, i.e. time create a TCP connection to a remote host, is always about 10ms, even when the ping is much higher. For example my ICMP ping to the time server 0.uk.pool.ntp.org (192.238.80.20) is about 160ms, but my TCP ping is about 10ms. I get the same result for almost any server on the internet anywhere in the world on any port, the TCP ping varies between 3ms and 12ms.
This implies that something local to my internet connection is intercepting my TCP connections, responding to my TCP connection requests and forwarding on the request to the remote host, e.g. a TCP proxy server, or firewall. The ping and TCP connection time to my broadband router is 1ms or under so its not my equipment. So I assume BT have some device on my connection path.
Has anyone experienced similar issues or knows what is causing this? Is it Parental Control network filters - I thought these worked by blocking DNS requests not by proxying and filtering traffic?

[Solved]TCP connection blocked in SYN_SENT status

Similar Messages

Maybe you are looking for