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...

Similar Messages

  • 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 correct close database connection after report generation

    Hello
    I have problem a with alive database connection after report creation and report  closing. How to properly to close connection to database?
    Best regards
    Edited by: punkers84 on Jun 17, 2011 10:38 AM

    that's what I am doing... after viewing the report, I call the close method on the window closing event of the container window. but the connection is still open. I had a lot of other issues with my jdbc driver but after downgrading to an older version those issues are resolved.Only this one is still there! Is there any other way to close the connection (like using dbcontroller or etc.)?

  • Can I close the connection after sending immediately on the server?

    I have a C/S program. On the server side, the process as following:
    1. accept (blocking)
    2. //a connection is established
    using a new socket to receive request data from client
    3. business processing ... (maybe several seconds)
    4. send response data to client
    5. close socket immediately
    6. listening continuely again
    The server side is running on linux and writed by Java, and client is running on windows and writed by C++ Builder.
    My problem is:
    1. if the server is running on windows, everything is OK.
    2. if the server is running on linux (that is exprcted), the client can not receive the response data from server, the client program said the connection is unavailable when he read from socket blockingly.
    3. if I add some delay, e.g. 500ms, between sending response and close the connection, the client can receive response normally.
    why above?
    thanks for help.
    Jack

    Sorry, long time to go away.
    package test.server;
    import java.io.InputStream;
    import java.io.OutputStream;
    import java.net.ServerSocket;
    import java.net.Socket;
    public class EchoServer {
         private int port; // listened port
         private ServerSocket ssock; // the server's ip
         public EchoServer(String host, int port) {
              this.port = port;
              // Create a ServerSocket
              try {
                   ssock = new ServerSocket(port);
                   SocketAddress addr = new InetSocketAddress(host, port);
                   ssock.bind(addr);
              } catch (Exception ex) {
                   ex.printStackTrace();
              new HandleThread().start();
         public class HandleThread extends Thread {
              public int ntohl(byte[] bytes, int offset) {
                   int length1 = ((((int) bytes[offset + 0]) << 24) & 0xff000000);
                   int length2 = ((((int) bytes[offset + 1]) << 16) & 0x00ff0000);
                   int length3 = ((((int) bytes[offset + 2]) << 8) & 0x0000ff00);
                   int length4 = ((((int) bytes[offset + 3]) << 0) & 0x000000ff);
                   return length1 + length2 + length3 + length4;
              public void run() {
                   InputStream in = null;
                   OutputStream out = null;
                   try {
                        while (true) {
                             System.out.println("Start Listening...  [" + port + "]");
                             Socket clisock = ssock.accept();
                             //clisock.setSoLinger(true, 1);
                             System.out.println( "SOLinger:" + clisock.getSoLinger());
                             try {
                                  System.out.println("Accepted Client Socket...  [" + clisock + "]");
                                  in = clisock.getInputStream();
                                  out = clisock.getOutputStream();
                                  // receive four bytes length
                                  byte[] lenbuff = new byte[4];
                                  in.read(lenbuff, 0, 4);
                                  int len = ntohl(lenbuff, 0);
                                  byte[] buff = new byte[len];
                                  in.read(buff, 0, len);
                                  System.out.println("Received length&#65306;" + len + "  " + new String(buff));
                                  Thread.sleep(1000);
                                  out.write(lenbuff);
                                  out.write(buff);
                                  out.flush();
                                  //Thread.sleep(500);
                                  System.out.println("Send finished&#12290;");
                             } catch (Exception ex) {
                                  ex.printStackTrace();
                             } finally {
                                  if (in != null) {
                                       try {
                                            in.close();
                                       } catch (Exception ex) {
                                  if (out != null) {
                                       try {
                                            out.close();
                                       } catch (Exception ex) {
                                  if (clisock != null) {
                                       try {
                                            long time00 = System.currentTimeMillis();
                                            clisock.close();
                                            System.out.println( "close socket&#65306;[" + (System.currentTimeMillis() - time00) + "]");
                                       } catch (Exception ex) {
                   } catch (Exception ex) {
                        ex.printStackTrace();
         public static void main(String[] args) throws Exception {
              if( args.length == 2 ) {
                   new EchoServer(args[0], Integer.parseInt(args[1]));
              } else if( args.length == 2 ) {
                   new EchoServer("127.0.0.1", Integer.parseInt(args[0]));
              } else {
                   new EchoServer("127.0.0.1", 16000);
    }In my application, the package is following:
    length(4bytes) + data
    I have a simple WinSocket Client, send data to this server and receive the response,the sending is OK, Server can receive all messages.But when client is ready to receive data, the winsock call return WSAECONNRESET(10054).
    If I uncomment "Thread.sleep(500);", it means wait some time before close socket, the client can receive all response data.
    why?

  • How to close ORMI connections after EJB lookup?

    I am using an InitialContext to look up my EJBs, like this:
    Hashtable env = new Hashtable();
    env.put(Context.INITIAL_CONTEXT_FACTORY, "oracle.j2ee.rmi.RMIInitialContextFactory");
    env.put(Context.PROVIDER_URL, "ormi://localhost:23891/current-workspace-app");
    env.put(Context.SECURITY_PRINCIPAL, username);
    env.put(Context.SECURITY_CREDENTIALS, password);
    ic = new InitialContext(env);
    beanHome = (EJBHome)ic.lookup(beanHomeName);
    ic.close();I have been testing this on JDeveloper 10.1.3 and the embedded OC4J.
    This code gave me the problem that the user's credentials were only retireved once while the OC4J instance was alive. So if a user's permissions were changed, they would not be updated for EJB access.
    I then found this document: Excessive ORMI Connections Created, which gave me a clue to use env.put("oracle.j2ee.rmi.loadBalance", "context");
    However, I am concerned with the other part of that release note which states:
    "Closing the context does not cause the connection to be closed. Doing this repeatedly will result in performance degredation."
    Does anyone know how to forcibly close the ORMI connection that is created, or whether it will be released automatically?

    the sample shows how to clear RAS and Enterprise resources after viewing report.
    1. If you use unmanaged RAS - as I can see you using setReportAppServer, then remove the enterprise related stuff : instantiating and cleaning code.
    The sample code is meant to give you an idea on how you can release the resources after done with viewing report. In your case all you need to do for cleaning is call close() on ReportDocumentObject. The sample will need to be modified for your requirements.

  • Many SQL TCP connections after starting addons

    Hi experts,
    we encounter some problematic behaviour in a producive environment with 45 clients. After starting 4 custom addons the "sqlserv.exe"  16 - 20 TCP IP connections are opened and stay opened as long as the client+addons are running.
    The addons are UI and DI (SSO) and they are performing maybe one or two recordset queries, which are closed and GC immediatly.
    We experienced some client crashes which we traced back to SAP/SQL Server inresponsivity - some of sqlserv.exe instances have a latency of  almost a second.
    The server is high end ( Xeon E5 2620,64GB RAM,dedicated SAS HD for each DB ,Windows Server 2008 Enterprise, MSSQL 2012, domain) and is laughing about duties .
    In 1st development environment same problem ( domain ) , in standalone 2nd environment not reproduceable.
    Difference : domain ( RSP -> off and  firewall -> but is LAN open, no rules )
    I know this is more an administration problem  but it occurs only  after starting addons.
    SBO 9.0 PL 8
    Has anyone experienced the same problem or has an idea ?
    thanks,
    Maik

    Hi Eric,
    thanks for your response.
    I am using only DI API Recordset and DataTable to read from DB. If I use direct SQL queries I can see them opening and closing ( what is expected ) - so no problem there.
    My main concern is that I can't reproduce the behaviour on 2 standalone development machines which are not part of the domain. Also pure DI API connections ( no SSO ) don't seem to be affected. All in all it is very frustrating for my customer to have an highend server + good infrastructure+ uptodate desktops and SBO  is crashing constantly because of memory leaks and now also because of SQL problems.
    regards,
    Maik

  • TCP custom step closes connection after Write operation

    I'm working on a project which requires me to send the command 0x02+"TIME"+0x06+"BASIC"+0x03+0x0D+0x0A  (hex values correspond to unprintable ascii) to a server. The server is expected to respond with the date and time. I am using the custom TCP steptype found here:http://sine.ni.com/apps/we/niepd_web_display.​display_epd4?p_guid=B6A6CBB49F7F2CB1E034080020E748​61&p_node=DZ52236&p_source=external
    I organized the steps like so: TCPConnect->TCPWrite->TCPRead->TCPDisconnect. The problem is that there is an error after TCPWrite and the process stops, so I am unable to read any data. The error message I get is "Error (No connection established)". The network guys say that it might be an issue with Teststand not setting the socket linger parameter, so the server closes the connection after the write command.
    I greatly appreciate any effort to fixing this problem, or providing an alternate solution to sending and receiving information through tcp with Teststand.
    -Hieu Huynh

    Hi HIeu,
    Were you able to get the example that is inlcuded in that zip file
    working at all? I would say try that with some sort of standard tcp
    connection that doesn't require any special inputs and see if you can
    get that to function on your workstation.
    Let me know, thanks Hieu.
    Dan Weiland

  • Using LabVIEW 6i w Win NT or 95/98 et al: how do you keep a TCP/IP open connection 'open'. The application closes the connection even though the refnum is still active (valid.)

    Actually, I open the TCP/IP connection and pass the connection ID through. Each command to/from (cycle) the UUT successfully executes. The refnum for the connection ID is then passed via a shift register in the while loop. i am using the type cast (4X) function to determine the validity of the connection and case statements. If the refnum is non-zero it assumes the connection is still open; if the result is zero, then the connection is closed and a new session opened in that case. What is happening is that the connection has closed and the refnum is still nonzero after the type cast function; su
    bsequent commands to the UUT then produce Error 1 for the TCP/IP function (there was no open connection, so there could be no write occurrence.) Obviously, this probably shouldn't be happening. If someone can give me some idea of what I am not doing, or am doing wrong, I sure would appreciate it. In the event that I open and close a connection for each command to(from)(cycle) the UUT everything works. It is extremely slow. The connection should remain open according to all the pointers in the Help and TCP/IP function descriptions. Some of this application is proprietary, so not sure how much of an example I could use to illustrate from a VI, but if this doesn't get any where, I will see what i can do to better illustrate the problem...Thanks. T.Raper

    I believe this is a related question. I am developing a LV application the uses TCP/IP to control up to 8 devices-under-test (DUT) at one time. They start and finish testing at arbitrary times relative to each other, and the IP addresses are not known until the DUT arrives. I have some question on what is the best way to manage the TCP/IP handles.
    Presently, I have 8 Global IP addresses (one per testing site) that are updated as DUTs arrive and depart, and then whenever I need to communicate with a DUT I use TCP-Open, Write/Read, and TCP-Close. I do this Open/Write/Close each time there is a message to be sent to a DUT. This is basically working, but I notice that the OS (Windows XP or 2000) is running through local TCP/IP ports at a ferocious rate due to the TIME_WAIT behavior of Closed TCP/IP ports (It takes many minutes for a local port to become available again after being closed). If I am not careful, I can quickly exhaust the pool of OS ports by using tight polling loops or other very quick DUT accesses. I have tried not to do that in order to avoid running out of handles, but it is still very wasteful of ports.
    While it is working, I feel so dirty burning through these handles like this since they appear to be a precious resource. I really cannot easily merge multiple Read/Writes into a single Open/Close since there are dozens of otherwise unrelated tests that communicate with the DUT as a part of their functionality. The tests are even in different subVI's that are accessed via a vi-server, and only one is loaded at a time.  
    I thought that a cute idea would be to cache the handles in Globals, and wrap the Open to use the cache if valid, but reading this thread is making me think it is a lot of effort -- I believe I would need to keep a VI running as a "IP Connection Server" at all times and use some form of messaging to get it to Open/Close TCP connections as needed. Since the DUTs arrive at aribitrary times, and with random IP addresses, I cannot establish all the TCP handles ahead of time -- they would need to be created dynamically. It is much more difficult than simply keeping the Connection IDs in global variables -- the VI that Opened them must not be allowed to terminate.
    So... I am curious...... is it really that bad to Open/Close as frequently as I am doing it? Does it make me a bad person? I understand it is inefficient use of time, but the simplicity it brings to the structure seems huge, and the DUT is very slow anyway. And if it is bad, are they any more recent thoughts on alternatives? Do VISA handles behave the same way as TCP handles (ie. auto-close themselves upon exit of the VI that Opened them) ?
    Message Edited by Mike Seibel on 11-28-2005 07:55 PM
    Message Edited by Mike Seibel on 11-28-2005 08:00 PM
    Message Edited by Mike Seibel on 11-28-2005 08:01 PM

  • What happends if I dont close the connection

    Hi,
    I would like to know what happends if I dont close the connection after processing. we wont get any compile time & run time error if you dont close the connection. But why we used to close the connetion. Any specific reason for this. Please let me know.
    Regards,
    Satish

    What happens if you don't close a connection? It depends on how many connections you open and how long your program keeps running.
    Let's start with the case of a standalone program that runs for a little while then exits.
    While the program is running, the operating system maintains a network connection to the database server for each open database connection; there are system limits on the number of open network connections, although this is usually a very high number. Also, every open connection to a database uses resources of the database; many databases have limits on the number of connections they can have open at once. Some database products or configurations (Oracle in "dedicated" mode) will also start a seperate process on the server for each open connection; too many open connections and these processes start swapping out to disk, too many more and the server runs out of memory.
    When the program exits, the operating system will close any open network connections; the database server will also recognize that the network connections are closed. If the database supports transactions and the connection was in a transactional mode and there were uncommitted transactions, then the uncommitted transactions will be rolled back. Ultimately, all the database resources get released (assuming there are no bugs in the database program).
    Thus, a program that runs for a few minutes, commits all its transactions and exits without closing connections doesn't do major harm; the operating systems of both the client and the database server clean up the network connection and the database itself cleans up the database connection. It's all designed this way because programs sometimes crash; you can't have a system/database that breaks when that occurs... However, this cleanup is not always absolutely immediate on program exit; it usually takes a short time, seconds to minutes, for everything to clean up. Therefore, if the same programs is run over and over real fast, it becomes possible to exhaust a resource, such as memory or network connections. For a quick little test program that's run once and that's it, no problem...
    Now for a long running prgram, such as a web application that will run for days or months...
    As I've alluded to above, each database connection uses system resources, both on the client machine and on the database server. When a connection is maintained open, those resources are tied up; there's always a limit on the total number of connections that can be supported, although with the right software, hardware and database configurations that limit can be a huge number, tens of thousands. For other systems, it might be a low number, hundreds or less. Whatever it is, the program could potentially reach that limit and cause something to fail. If it doesn't reach that limit (or cause another program to push past the limit) then there's no problem (other than a potential performance impact).
    Now within a Java program, the JDBC standard requires that when an open database connection object is garbage collected, the connection is first closed. Assuming your driver conforms to the standard in this regard, and assuming no resource limit gets exceeded, then a long running program could open and abandon connections and let the garbage collector close and clean up. However, garbage collection is unpredictable, and connections are often sufficiently long lived that they get moved out of the "Eden" memory space and into the space of long-lived objects. These objects are only garbage collected when a "full" garbage collection takes place; a "partial" collection only examines the "Eden" space. Thus, depending on the applications load and memory usage and connection usage pattern and garbage collection configuration, an abandonded connection might not be garbage collected for hours or even days, greately increasing the chances that you run out of resources.
    In other words, not closing your connections in a long running program is a really really bad idea.

  • Open and close RFC connection with portals...

    Hi Experts,
    I created a RFC having a query which is taking a long time to execute. So i want to close RFC connection with portals which is via java connector(JCO)  before that query and open the connction again after that query.
    Please advice is it possible to achieve this. If yes, then how.
    Regards,
    Guddan

    Hi Guddan,
    I created a RFC having a query which is taking a long time to execute. So i want to close RFC connection with portals which is via java connector(JCO) before that query and open the connction again after that query.
    I guess i will need to understand your requirement a little more in detail, as i understand you have an RFC which has a query within to fetch some data and is taking a long time to do so. In the meantime you don't want to keep the connection open?
    My question would be, Is the role of this RFC to only execute the query and fetch the data or does it do something else?
    If it does other things and these are independent of the query execution, then you can span a parallel call within the RFC to execute the query and in the meantime the RFC does the other things (or vice versa) hence reducing the overall time taken.
    If the sole purpose of this RFC is to execute the query, then you will not be able(i mean to say there is no simple and direct way of doing this) to close the connection after the Query is started and re-establish the connection after its execution, for a simple reason that - how will you know if the query has completed it's execution, so that you can establish the connection back.
    Alternate solutions, make this a two way asynchronous call, 1) You invoke the RFC asynchronously and close the connection, the RFC in turn will execute the query and transfer the data to JCO via another RFC call.
    If this needs to be a synchronous call, then you will need to optimize the query to its best.
    Regards,
    Chen

  • WRT54G2 V1 stops routing after some simultaneous tcp connections

    Hello guys, this issue with my WRT54G2:
    - when i open more than 2 or 3 browser windows or anything that access internet, it stop routing
    - shutdown and power up make it work again (then stops again after some simultaneous tcp connections)
    - hard reset dont work
    - WRT54G2 V1 Firmware Version: 1.0.04  
    - please help!

    Adjust the MTU size of the router. To determine the value of MTU that should be set on the router, follow the link below.
    Determining and setting up the correct MTU size

  • 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

  • TCP connections alive well after Firefox is closed

    According to Sysinternals TCPView, I have several TCP connections that stay open (established) well after I close and exit Firefox, I'm talking 8 hours after. Normal connections close within minutes if shutting down Firefox. I'd post a pic, but there is no option for it so here's a paste (commas instead of tabs):
    process/protocol, local address, remote asddress, state
    firefox.exe.7108, TCP, russ-l675,gt,rr,com.53713, dfw06s17-in-17.1e100.net:http, established
    firefox.exe.7108, TCP, russ-l675,gt,rr,com.54103, 203.30.164.5:http, established
    I can (and do!) manually close these connections and they don't come back until I restart FF.
    Thanks!
    Russ

    Yes, but it's been disabled for over a week and this is still happening. Just to be sure, I will uninstall the add-ons. One of these resolves to Australia and the other to a Google server. Am I being watched? This info comes up from the "odd" IP address:
    MarkMonitor is the Global Leader in Online Brand Protection.
    MarkMonitor Domain Management(TM)
    MarkMonitor Brand Protection(TM)
    MarkMonitor AntiPiracy(TM)
    MarkMonitor AntiFraud(TM)
    Professional and Managed Services
    Visit MarkMonitor at www.markmonitor.com
    Contact us at 1 (800) 745-9229
    In Europe, at +44 (0) 203 206 2220
    The Data in MarkMonitor.com's WHOIS database is provided by MarkMonitor.com for information purposes, and to assist persons in obtaining information about or related to a domain name registration record. MarkMonitor.com does not guarantee its accuracy. By submitting a WHOIS query, you agree that you will use this Data only for lawful purposes and that, under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (2) enable high volume, automated, electronic processes that apply to MarkMonitor.com (or its systems). MarkMonitor.com reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy.
    Registrant:
    DNS Admin
    Google Inc.
    1600 Amphitheatre Parkway
    Mountain View CA 94043
    US
    [email protected] +1.6502530000 Fax: +1.6506188571
    Domain Name: 1e100.net
    Registrar Name: Markmonitor.com
    Registrar Whois: whois.markmonitor.com
    Registrar Homepage: http://www.markmonitor.com
    Administrative Contact:
    DNS Admin
    Google Inc.
    1600 Amphitheatre Parkway
    Mountain View CA 94043 US
    [email protected] +1.6502530000 Fax: +1.6506188571
    Technical Contact, Zone Contact:
    DNS Admin
    Google Inc.
    1600 Amphitheatre Parkway
    Mountain View CA 94043 US
    [email protected] +1.6502530000 Fax: +1.6506188571
    Created on..............: 2009-09-24.
    Expires on..............: 2019-09-24.
    Record last updated on..: 2012-04-20.
    Domain servers in listed order:
    ns2.google.com
    ns3.google.com
    ns1.google.com
    ns4.google.com
    MarkMonitor is the Global Leader in Online Brand Protection.
    MarkMonitor Domain Management(TM)
    MarkMonitor Brand Protection(TM)
    MarkMonitor AntiPiracy(TM)
    MarkMonitor AntiFraud(TM)
    Professional and Managed Services
    Visit MarkMonitor at www.markmonitor.com
    Contact us at 1 (800) 745-9229
    In Europe, at +44 (0) 203 206 2220
    Russ

  • SbRIO-9612 unable to close a TCP connection without causing TCP failure

    Hello,
    I'm working on a multi-server (sbRIO-9612's), multi-client (Windows PCs) application which uses the STM 2.0 libraries and LV2009 SP1.  The server listens on a UDP port for the client to send a message - once sent, the server opens the TCP connection to the client and all is well . . .
    . . . until I added a "hearbeat" message to monitor for down connections.  Once the TCP connection has been extablished, the client PC sends a TCP message (a request for the number of clients connected) to the server sbRIO-9612 every 5 seconds - both the client and server are coded to close the connection if a message is not received within 10 seconds.  The client-side app works fine - if the TCP message is not returned in 10 seconds, the connection is closed and a new UDP message is sent to re-establish it.
    The server-side is the problem - if no message is received in 10 seconds, the TCP connection is closed o.k. (no errors), but the server will no longer allow new TCP connections to be established unless it's rebooted.  It seems to work fine if I leave the non-communicating TCP connections open on the server-side, but I can see this leading to problems after several clients have disconnected without notifying the server properly.
    Interestingly, if the client closes the TCP connection properly (via TCP Close in LV), the server detects it fine and there is no problem.
    I'm allowing the operating system on both sides to select the TCP port to use.
    Any help is greatly appriciated - thank you!
    Al

    Hi Al,
    Thanks for the update -- I'm glad that you were able to find that the issue wasn't actually with the TCP VIs, and moreover that LabVIEW 2010 SP1 seems to have resolved the issue. I would still recommend combing through the code on the RT end to ensure that the LabVIEW 2010 SP1 upgrade really did 'fix' the underlying issue. It's somewhat strange that a version upgrade resolved TCP communication issues that you were having. I just want to be sure that the solution is a truly stable one.
    Sanjay C.
    Embedded Software Product Manager| National Instruments

  • TCP connections on Cisco ASA disconnects the database session every 30 Minutes

    Right after a firmware upgrade form 8.4.2 to 8.4.7   on our ASA 5540:
    the database app that makes a tcp connection with the database  loses connection to the database servers on the inside of the firewall
    -Nothing changed on the process servers.
    -Nothing but firmware version changed on the firewalls.
    -Rebooting did not help.
    -Connections don't always drop every 30 minutes, but it's still almost exactly at that time, with a 90% chance of it happening. And it reestablishes in about 52 second
    -The client is not willingly terminating the connections to the database servers on the inside. The connection is just going away.

    I am not seeing any error in the logs in ASA but in our client we see:
    Latest from PROD (times are in UTC):
    Sun Apr 13 10:22:10 2014 - ERR: Read from the server failed (err[36],sev[78],state[0],line[0],server[],proc[],sql[exec sp_events_insupd :p1,:p2,:p3,:p4,:p5,:p6,:p7,:p8,:p9,:p10,:p11,:p12,:p13,:p14,:p15,:p16,:p17],err_type[client])
    Sun Apr 13 11:47:09 2014 - ERR: Read from the server failed (err[36],sev[78],state[0],line[0],server[],proc[],sql[exec sp_events_insupd :p1,:p2,:p3,:p4,:p5,:p6,:p7,:p8,:p9,:p10,:p11,:p12,:p13,:p14,:p15,:p16,:p17],err_type[client])

Maybe you are looking for