Search Results

Search found 12283 results on 492 pages for 'tcp port'.

Page 10/492 | < Previous Page | 6 7 8 9 10 11 12 13 14 15 16 17  | Next Page >

• sites now not responding on port 80 [closed]

  - by JohnMerlino

  Possible Duplicate: unable to connect site to different port I was trying to resolve an issue with getting a site running on a different port: unable to connect site to different port But somehow it took out all my other sites. Now even the ones that were responding on port 80 are no longe responding, even though I did not touch the virtual hosts for them. I get this message now: Oops! Google Chrome could not connect to mysite.com However, ping responds: ping mysite.com PING mysite.com (64.135.12.134): 56 data bytes 64 bytes from 64.135.12.134: icmp_seq=0 ttl=49 time=20.839 ms 64 bytes from 64.135.12.134: icmp_seq=1 ttl=49 time=20.489 ms The result of telnet: $ telnet guarddoggps.com 80 Trying 64.135.12.134... telnet: connect to address 64.135.12.134: Connection refused telnet: Unable to connect to remote host

  Read the article

• tcp flags in iptables: What's the difference between RST SYN and RST and SYN RST ? When to use ALL?

  - by Kris

  I'm working on a firewall for a virtual dedicated server and one of the things I'm looking into is port scanners. TCP flags are used for protection. I have 2 questions. The rule: -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -j DROP First argument says check packets with flag SYN Second argument says make sure the flags ACK,FIN,RST SYN are set And when that's the case (there's a match), drop the tcp packet First question: I understand the meaning of RST and RST/ACK but in the second argument RST SYN is being used. What's the difference between RST SYN and RST and SYN RST ? Is there a "SYN RST" flag in a 3 way handshake ? Second question is about the difference between -p tcp --tcp-flags SYN,ACK,FIN,RST SYN -j DROP and -p tcp --tcp-flags ALL SYN,ACK,FIN,RST SYN -j DROP When should ALL be used ? When I use ALL, does that mean if the tcp packet with the syn flag doesn't have the ACK "and" the FIN "and" the RST SYN flags set, there will be no match ?

  Read the article

• Single TCP-CLOSE_WAIT connection brings down application till restart

  - by broun

  Recently found a behaviour where my application had a connection in TCP Close_wait state till the app was restarted (after about 5 hours). But during this period the SUnreclaim space was also increasing constantly and went down on restart. The application is runnning on a rhel5 os and Im not very familiar with the memory management system. Would appreciate if someone clould tell me what extactly is the Ureclaim space and why it is increasing in sync with the close_wait.

  Read the article

• SUnreclaim size increasing in syc with a TCP-CLOSE_WAIT till application restart

  - by maver1k

  Recently found a behaviour where my application had a connection in TCP Close_wait state till the app was restarted (after about 5 hours). But during this period the SUnreclaim space was also increasing constantly and went down on restart. The application is runnning on a rhel5 os and Im not very familiar with the memory management system. Would appreciate if someone clould tell me what extactly is the Ureclaim space and why it is increasing in sync with the close_wait. Thanks.

  Read the article

• triple duplicate acknowledgement in TCP congestion control

  - by Salvador Dali

  If this doesn't belong here, please tell me where is an appropriate place for such question. I am trying to understand ideas behind tcp congestion control mechanisms, and I am failing to understand why we need triple duplicate acknowledgement to trigger window change. In my opinion, double duplicate acknowledgement will be enough to get that the previous package is lost. So why we need the third ack?

  Read the article

• Persistent TCP connection in DMZ

  - by G33kKahuna

  A vendor is requesting to allow persistent tcp (not port 80) connection between a server in the DMZ and the internal network. I don't have much experience with this setting. Can anyone shed some light on disadvantages of allowing persistent connection? Guidance is much apprciated.

  Read the article

• Alternate Out of Order TCP Packets problem

  - by Sunil

  I am having a network of windows and embedded nodes connected on a series of cisco switch. I have been seeing some serious network problems from few days. Used wireshark to capture the network trace and see every alternate tcp packets being marked as "out of order". Any pointers on how to troubleshoot this problem?

  Read the article

• VirtualBox Port Forward not working when Guest IP *IS* specified (while doc says opposite)

  - by Patrick

  Trying to port forward from host (Mac OS X) 127.0.0.1:8282 - guest (CentOS)'s 10.10.10.10:8080. Existing port forwards include 127.0.0.1:8181 and 9191 to guest without any IP specified (so whatever it gets through DHCP, as explained in the documentation). Here is how the non-working binding was added: VBoxManage modifyvm "VM name" --natpf1 "rule3,tcp,127.0.0.1,8282,10.10.10.10,8080" Here is how the working ones were added: VBoxManage modifyvm "VM name" --natpf1 "rule1,tcp,127.0.0.1,8181,,80" VBoxManage modifyvm "VM name" --natpf1 "rule2,tcp,127.0.0.1,9191,,9090" And by "non-working", I of course mean not listening (as a prerequisite to forwarding): $ lsof -Pi -n|grep Virtual|grep LISTEN VirtualBo 27050 user 21u IPv4 0x2bbdc68fd363175d 0t0 TCP 127.0.0.1:9191 (LISTEN) VirtualBo 27050 user 22u IPv4 0x2bbdc68fd0e0af75 0t0 TCP 127.0.0.1:8181 (LISTEN) There should be a similar line above but with 127.0.0.1:8282. Just to be clear, this port is listening perfectly fine on the guest itself. And when I remove the guest IP (i.e., clear the 10.10.10.10) the forward works fine, albeit to eth0 (not eth1 where I need it). I can tcpdump and watch the traffic flow back and forth. And yes, I've disabled iptables entirely while testing -- it's not getting blocked anywhere on the guest. As VirtualBox writes in their documentation, you are required to specify the guest IP if it's static (makes sense, no DHCP record it keeps): "If for some reason the guest uses a static assigned IP address not leased from the built-in DHCP server, it is required to specify the guest IP when registering the forwarding rule:". However, doing so (as I need to), seems to break the port forward with nary a report in any log file I can find. (I've reviewed everything in ~/Library/VirtualBox/). Other notes: While I used the above command to add the third rule, I've also verified it showed up correctly in GUI and then removed/re-added from there just to make sure). This forum link -- while very dated -- looks somewhat related in that a port forward to a static IP was not appearing (perhaps they think due to lack of gratuitous arp being sent for host to know IP is there/avail?). Anyway, what gives? Is this still buggy? Any suggestions? If not, easy enough workarounds? What's interesting is that this works perfectly fine on another user's Mac, however he's running a slightly older version (4.3.6 v. 4.3.12).

  Read the article

• Windows TCP timeout

  - by hs2d

  Is there on windows any default timeout for tcp connection? So when no answere is received the connection would be closed. Why im asking is that on one machine the connection is closed afther 5 minutes.(Windows XP) Running the same client - server connection on other machine the connection is kept open forever like it should be. Or maybe there is some global java virtual machine setting somewhere i should know about? The server and client run on the same local machine

  Read the article

• Can't seem to get C TCP Server-Client Communications Right

  - by Zeesponge

  Ok i need some serious help here. I have to make a TCP Server Client. When the Client connects to server using a three stage handshake. AFterwards... while the Client is running in the terminal, the user enters linux shell commands like xinput list, ls -1, ect... something that uses standard output. The server accepts the commands and uses system() (in a fork() in an infinite loop) to run the commands and the standard output is redirected to the client, where the client prints out each line. Afterward the server sends a completion signal of "\377\n". In which the client goes back to the command prompt asking for a new command and closes its connection and exit()'s when inputting "quit". I know that you have to dup2() both the STDOUT_FILENO and STDERR_FILENO to the clients file descriptor {dup2(client_FD, STDOUT_FILENO). Everything works accept when it comes for the client to retrieve system()'s stdout and printing it out... all i get is a blank line with a blinking cursor (client waiting on stdin). I tried all kinds of different routes with no avail... If anyone can help out i would greatly appreciate it TCP SERVER CODE include #include <sys/socket.h> #include <stdio.h> #include <string.h> #include <netinet/in.h> #include <signal.h> #include <unistd.h> #include <stdlib.h> #include <errno.h> //Prototype void handle_client(int connect_fd); int main() { int server_sockfd, client_sockfd; socklen_t server_len, client_len; struct sockaddr_in server_address; struct sockaddr_in client_address; server_sockfd = socket(AF_INET, SOCK_STREAM, 0); server_address.sin_family = AF_INET; server_address.sin_addr.s_addr = htonl(INADDR_ANY); server_address.sin_port = htons(9734); server_len = sizeof(server_address); bind(server_sockfd, (struct sockaddr *)&server_address, server_len); /* Create a connection queue, ignore child exit details and wait for clients. */ listen(server_sockfd, 10); signal(SIGCHLD, SIG_IGN); while(1) { printf("server waiting\n"); client_len = sizeof(client_address); client_sockfd = accept(server_sockfd, (struct sockaddr *)&client_address, &client_len); if(fork() == 0) handle_client(client_sockfd); else close(client_sockfd); } } void handle_client(int connect_fd) { const char* remsh = "<remsh>\n"; const char* ready = "<ready>\n"; const char* ok = "<ok>\n"; const char* command = "<command>\n"; const char* complete = "<\377\n"; const char* shared_secret = "<shapoopi>\n"; static char server_msg[201]; static char client_msg[201]; static char commands[201]; int sys_return; //memset client_msg, server_msg, commands memset(&client_msg, 0, sizeof(client_msg)); memset(&server_msg, 0, sizeof(client_msg)); memset(&commands, 0, sizeof(commands)); //read remsh from client read(connect_fd, &client_msg, 200); //check remsh validity from client if(strcmp(client_msg, remsh) != 0) { errno++; perror("Error Establishing Handshake"); close(connect_fd); exit(1); } //memset client_msg memset(&client_msg, 0, sizeof(client_msg)); //write remsh to client write(connect_fd, remsh, strlen(remsh)); //read shared_secret from client read(connect_fd, &client_msg, 200); //check shared_secret validity from client if(strcmp(client_msg, shared_secret) != 0) { errno++; perror("Invalid Security Passphrase"); write(connect_fd, "no", 2); close(connect_fd); exit(1); } //memset client_msg memset(&client_msg, 0, sizeof(client_msg)); //write ok to client write(connect_fd, ok, strlen(ok)); // dup2 STDOUT_FILENO <= client fd, STDERR_FILENO <= client fd dup2(connect_fd, STDOUT_FILENO); dup2(connect_fd, STDERR_FILENO); //begin while... while read (client_msg) from server and >0 while(read(connect_fd, &client_msg, 200) > 0) { //check command validity from client if(strcmp(client_msg, command) != 0) { errno++; perror("Error, unable to retrieve data"); close(connect_fd); exit(1); } //memset client_msg memset(&client_msg, 0, sizeof(client_msg)); //write ready to client write(connect_fd, ready, strlen(ready)); //read commands from client read(connect_fd, &commands, 200); //run commands using system( ) sys_return = system(commands); //check success of system( ) if(sys_return < 0) { perror("Invalid Commands"); errno++; } //memset commands memset(commands, 0, sizeof(commands)); //write complete to client write(connect_fd, complete, sizeof(complete)); } } TCP CLIENT CODE #include <sys/types.h> #include <sys/socket.h> #include <stdio.h> #include <string.h> #include <netinet/in.h> #include <arpa/inet.h> #include <unistd.h> #include <stdlib.h> #include <errno.h> #include "readline.c" int main(int argc, char *argv[]) { int sockfd; int len; struct sockaddr_in address; int result; const char* remsh = "<remsh>\n"; const char* ready = "<ready>\n"; const char* ok = "<ok>\n"; const char* command = "<command>\n"; const char* complete = "<\377\n"; const char* shared_secret = "<shapoopi>\n"; static char server_msg[201]; static char client_msg[201]; memset(&client_msg, 0, sizeof(client_msg)); memset(&server_msg, 0, sizeof(server_msg)); /* Create a socket for the client. */ sockfd = socket(AF_INET, SOCK_STREAM, 0); /* Name the socket, as agreed with the server. */ memset(&address, 0, sizeof(address)); address.sin_family = AF_INET; address.sin_addr.s_addr = inet_addr(argv[1]); address.sin_port = htons(9734); len = sizeof(address); /* Now connect our socket to the server's socket. */ result = connect(sockfd, (struct sockaddr *)&address, len); if(result == -1) { perror("ACCESS DENIED"); exit(1); } //write remsh to server write(sockfd, remsh, strlen(remsh)); //read remsh from server read(sockfd, &server_msg, 200); //check remsh validity from server if(strcmp(server_msg, remsh) != 0) { errno++; perror("Error Establishing Initial Handshake"); close(sockfd); exit(1); } //memset server_msg memset(&server_msg, 0, sizeof(server_msg)); //write shared secret text to server write(sockfd, shared_secret, strlen(shared_secret)); //read ok from server read(sockfd, &server_msg, 200); //check ok velidity from server if(strcmp(server_msg, ok) != 0 ) { errno++; perror("Incorrect security phrase"); close(sockfd); exit(1); } //? dup2 STDIN_FILENO = server socket fd? //dup2(sockfd, STDIN_FILENO); //begin while(1)/////////////////////////////////////// while(1){ //memset both msg arrays memset(&client_msg, 0, sizeof(client_msg)); memset(&server_msg, 0, sizeof(server_msg)); //print Enter Command, scan input, fflush to stdout printf("<<Enter Command>> "); scanf("%s", client_msg); fflush(stdout); //check quit input, if true close and exit successfully if(strcmp(client_msg, "quit") == 0) { printf("Exiting\n"); close(sockfd); exit(EXIT_SUCCESS); } //write command to server write(sockfd, command, strlen(command)); //read ready from server read(sockfd, &server_msg, 200); //check ready validity from server if(strcmp(server_msg, ready) != 0) { errno++; perror("Failed Server Communications"); close(sockfd); exit(1); } //memset server_msg memset(&server_msg, 0, sizeof(server_msg)); //begin looping and retrieving from stdin, //break loop at EOF or complete while((read(sockfd, server_msg, 200) != 0) && (strcmp(server_msg, complete) != 0)) { //while((fgets(server_msg, 4096, stdin) != EOF) || (strcmp(server_msg, complete) == 0)) { printf("%s", server_msg); memset(&server_msg, 0, sizeof(server_msg)); } } }

  Read the article

• Tunneling a TCP/IP Connection through Remote Desktop Connection

  - by Kristopher Johnson

  There is a remote Windows server on a private network which I can connect to via Remote Desktop Connection. I would like to be able to make TCP/IP connections from my computer to other computers on that server's network. Remote Desktop Connection makes it possible to share printers, drives, and other local resources through the connection. Is there any way to "tunnel" a TCP/IP connection via RDC? I'd like something similar to the port-forwarding provided by SSH. I don't see any way to do this via RDC, but I'm hoping the capability is there and I just don't know about it.

  Read the article

• Looking for an unmanaged 4/8-port GBit Ethernet switch with a GBIC port

  - by Aaron Digulla

  I'm looking for a simple unmanaged switch with 4-8 GBit Ethernet ports and a fiber port (either as a GBIC slot or pre-installed with a 1000BASE-SX port). Anything you can recommend?

  Read the article

• Unix Shell/SSH config to allow TCP port forwarding without showing a command prompt

  - by Raphael K

  I'm running a Debian Linux. I'd like to have a user account that is able to connect via SSH for TCP-forwarding only, without a command prompt. e.g the following would work (from a remote computer): ssh -D1234 user@myhost but no command prompt would appear. Using a shell like /bin/false or /sbin/nologin is too restrictive as it doesn't even allow the user to log in. A shell that only allows the "exit" or Ctrl+D commands would do the job. I know that something similar is possible to allow only SFTP, but I can't find the equivalent for TCP forwarding. Thanks

  Read the article

• TCP RST right after FIN/ACK

  - by Nitzan Shaked

  I am having the weirdest issue: I have a web server which sometimes, only on very specific requests, will send a RST to the client after having sent the FIN datagram. First, a description of the setup: The server runs on an Ubuntu 12.04.1 LTS, which itself is a VM guest inside a Win7 x64 host, in bridged mode. ufw is disabled on the host The client runs on a iOS simulator, which runs on OS X Mountain Lion, which is a VM guest (hackintosh) inside a Win7 x64 host, in bridged mode. Both client and server are on the same LAN, one is connected to the home router via an Ethernet cable, and then other thru WiFi. I happened to glimpse over the server's http logs and found that the client sometimes issuing multiple subsequent identical requests. Further investigation led me to discover that this happens when the server sends a RST, and that the client is simply re-trying. I am attaching several tcpdump's: Good1 is the server-side tcpdump of a good session ("good" meaning no RST was generated). Good3 is another sever-side tcpdump of a good session. (The difference between Good1 and Good3 is the order in which ACK's were sent from the server to the client, ACK'ing the client's request. The client's request arives in 2 segements (specifically: one for the http headers, and another for a body containing an empty json object, "{}"). In Good1, the server ACK's both request segments, using 2 ACK segments, after the second request has arrived. In Good3, the server ACK's each request segment with an ACK segment as soon as the request segment arrives. Not that it should make a difference.) Bad1 is a dump, both client- and server-side, of a bad session. Bad2 is another bad session, this time server-side only. Note that in all "bad" sessions, the server ACK's each request segments immediately after having received it. I've looked at a few other bad sessions, and the situation is the same in all of them. But this is also the behavior in "Good3", so I don't see how that observation helps me, of for that matter why it should matter. I can't find any difference between good and bad sessions, or at least one that I think should matter. My question is: why are those RST's being generated? Or at least: how do I go about debugging this, or providing more info here that'll help? Edit 2 new facts that I have learned: Section 4.2.2.13 of the RFC (1122) (and Wikipedia, in the article "TCP", under "Connection Termination") says that a TCP application on one host may close the connection before it has read all of the data in its socket buffer, and in such a case the TCP on the host will sent a RST to the other side, to let it know that not all the data it has sent has been read. I'm not sure I completely understand this, since closing my side of the connection still allows me to read, no? It also means that I can't write any more. I am not sure this is relevant, though, since I see a RST after FIN. There are multiple complaints of this happening with wsgiref (Python's dev-mode HTTP server), which is exactly what I'm using. I'll keep updating as I find out more. Thanks! ~~~~~~~~~~~~~~~~~~~~ Good1 -- Server Side ~~~~~~~~~~~~~~~~~~~~ 13:28:02.308319 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [S], seq 94268074, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943308864 ecr 0,sackOK,eol], length 0 13:28:02.308336 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [S.], seq 1726304574, ack 94268075, win 14480, options [mss 1460,sackOK,TS val 326480982 ecr 943308864,nop,wscale 3], length 0 13:28:02.309750 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943308865 ecr 326480982], length 0 13:28:02.310744 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943308865 ecr 326480982], length 350 13:28:02.310766 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943308865 ecr 326480982], length 2 13:28:02.310841 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326480983 ecr 943308865], length 0 13:28:02.310918 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326480983 ecr 943308865], length 0 13:28:02.315931 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326480984 ecr 943308865], length 17 13:28:02.316107 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326480984 ecr 943308865], length 666 13:28:02.317651 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943308872 ecr 326480984], length 0 13:28:02.318288 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943308872 ecr 326480984], length 0 13:28:02.318640 IP 192.168.1.51.51479 > 192.168.1.132.5000: Flags [F.], seq 353, ack 685, win 8192, options [nop,nop,TS val 943308872 ecr 326480984], length 0 13:28:02.318651 IP 192.168.1.132.5000 > 192.168.1.51.51479: Flags [.], ack 354, win 1944, options [nop,nop,TS val 326480985 ecr 943308872], length 0 ~~~~~~~~~~~~~~~~~~~~ Good3 -- Server Side ~~~~~~~~~~~~~~~~~~~~ 13:28:03.311143 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [S], seq 1982901126, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943309853 ecr 0,sackOK,eol], length 0 13:28:03.311155 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [S.], seq 2245063571, ack 1982901127, win 14480, options [mss 1460,sackOK,TS val 326481233 ecr 943309853,nop,wscale 3], length 0 13:28:03.312671 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943309854 ecr 326481233], length 0 13:28:03.313330 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943309855 ecr 326481233], length 350 13:28:03.313337 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326481234 ecr 943309855], length 0 13:28:03.313342 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943309855 ecr 326481233], length 2 13:28:03.313346 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326481234 ecr 943309855], length 0 13:28:03.327942 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326481237 ecr 943309855], length 17 13:28:03.328253 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326481237 ecr 943309855], length 666 13:28:03.329076 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943309868 ecr 326481237], length 0 13:28:03.329688 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943309868 ecr 326481237], length 0 13:28:03.330361 IP 192.168.1.51.51486 > 192.168.1.132.5000: Flags [F.], seq 353, ack 685, win 8192, options [nop,nop,TS val 943309869 ecr 326481237], length 0 13:28:03.330370 IP 192.168.1.132.5000 > 192.168.1.51.51486: Flags [.], ack 354, win 1944, options [nop,nop,TS val 326481238 ecr 943309869], length 0 ~~~~~~~~~~~~~~~~~~~~ Bad1 -- Server Side ~~~~~~~~~~~~~~~~~~~~ 13:28:01.311876 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [S], seq 920400580, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943307883 ecr 0,sackOK,eol], length 0 13:28:01.311896 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [S.], seq 3103085782, ack 920400581, win 14480, options [mss 1460,sackOK,TS val 326480733 ecr 943307883,nop,wscale 3], length 0 13:28:01.313509 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943307884 ecr 326480733], length 0 13:28:01.315614 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943307886 ecr 326480733], length 350 13:28:01.315727 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326480734 ecr 943307886], length 0 13:28:01.316229 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943307886 ecr 326480733], length 2 13:28:01.316242 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326480734 ecr 943307886], length 0 13:28:01.321019 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326480735 ecr 943307886], length 17 13:28:01.321294 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307886], length 666 13:28:01.321386 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R.], seq 685, ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307886], length 0 13:28:01.322727 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943307891 ecr 326480735], length 0 13:28:01.322733 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R], seq 3103085800, win 0, length 0 13:28:01.323221 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943307892 ecr 326480736], length 0 13:28:01.323231 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R], seq 3103086467, win 0, length 0 ~~~~~~~~~~~~~~~~~~~~ Bad1 -- Client Side ~~~~~~~~~~~~~~~~~~~~ 13:28:11.374654 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [S], seq 920400580, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943307883 ecr 0,sackOK,eol], length 0 13:28:11.375764 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [S.], seq 3103085782, ack 920400581, win 14480, options [mss 1460,sackOK,TS val 326480733 ecr 943307883,nop,wscale 3], length 0 13:28:11.376352 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943307884 ecr 326480733], length 0 13:28:11.378252 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943307886 ecr 326480733], length 350 13:28:11.379027 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943307886 ecr 326480733], length 2 13:28:11.379732 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326480734 ecr 943307886], length 0 13:28:11.380592 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326480734 ecr 943307886], length 0 13:28:11.384968 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326480735 ecr 943307886], length 17 13:28:11.385044 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943307891 ecr 326480735], length 0 13:28:11.385586 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307886], length 666 13:28:11.385743 IP 192.168.1.51.51472 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943307892 ecr 326480736], length 0 13:28:11.385966 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R.], seq 685, ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307886], length 0 13:28:11.387343 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R], seq 3103085800, win 0, length 0 13:28:11.387344 IP 192.168.1.132.5000 > 192.168.1.51.51472: Flags [R], seq 3103086467, win 0, length 0 ~~~~~~~~~~~~~~~~~~~~ Bad2 -- Server Side ~~~~~~~~~~~~~~~~~~~~ 13:28:01.319185 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [S], seq 1631526992, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 943307889 ecr 0,sackOK,eol], length 0 13:28:01.319197 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [S.], seq 2524685719, ack 1631526993, win 14480, options [mss 1460,sackOK,TS val 326480735 ecr 943307889,nop,wscale 3], length 0 13:28:01.320692 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [.], ack 1, win 8235, options [nop,nop,TS val 943307890 ecr 326480735], length 0 13:28:01.322219 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [P.], seq 1:351, ack 1, win 8235, options [nop,nop,TS val 943307890 ecr 326480735], length 350 13:28:01.322336 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [.], ack 351, win 1944, options [nop,nop,TS val 326480736 ecr 943307890], length 0 13:28:01.322689 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [P.], seq 351:353, ack 1, win 8235, options [nop,nop,TS val 943307890 ecr 326480735], length 2 13:28:01.322700 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [.], ack 353, win 1944, options [nop,nop,TS val 326480736 ecr 943307890], length 0 13:28:01.326307 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [P.], seq 1:18, ack 353, win 1944, options [nop,nop,TS val 326480737 ecr 943307890], length 17 13:28:01.326614 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [FP.], seq 18:684, ack 353, win 1944, options [nop,nop,TS val 326480737 ecr 943307890], length 666 13:28:01.326710 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [R.], seq 685, ack 353, win 1944, options [nop,nop,TS val 326480737 ecr 943307890], length 0 13:28:01.328499 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [.], ack 18, win 8234, options [nop,nop,TS val 943307896 ecr 326480737], length 0 13:28:01.328509 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [R], seq 2524685737, win 0, length 0 13:28:01.328514 IP 192.168.1.51.51473 > 192.168.1.132.5000: Flags [.], ack 685, win 8192, options [nop,nop,TS val 943307896 ecr 326480737], length 0 13:28:01.328517 IP 192.168.1.132.5000 > 192.168.1.51.51473: Flags [R], seq 2524686404, win 0, length 0

  Read the article

• How to get virtual com-port number if DBT_DEVNODES_CHANGED event accrues?

  - by Nick Toverovsky

  Hi! Previously I defined com-port number using DBT_DEVICEARRIVAL: procedure TMainForm.WMDEVICECHANGE(var Msg: TWMDeviceChange); var lpdb : PDevBroadcastHdr; lpdbpr: PDevBroadCastPort; S: AnsiString; begin {????????? ?????????} lpdb := PDevBroadcastHdr(Msg.dwData); case Msg.Event of DBT_DEVICEARRIVAL: begin {??????????} if lpdb^.dbch_devicetype = DBT_DEVTYP_PORT {DBT_DEVTYP_DEVICEINTERFACE} then begin lpdbpr:= PDevBroadCastPort(Msg.dwData); S := StrPas(PWideChar(@lpdbpr.dbcp_name)); GetSystemController.Init(S); end; end; DBT_DEVICEREMOVECOMPLETE: begin {????????} if lpdb^.dbch_devicetype = DBT_DEVTYP_PORT then begin lpdbpr:= PDevBroadCastPort(Msg.dwData); S := StrPas(PWideChar(@lpdbpr.dbcp_name)); GetSystemController.ProcessDisconnect(S); end; end; end; end; Unfortunately, the hardware part of a device with which I was working changed and now Msg.Event has value BT_DEVNODES_CHANGED. I've read msdn. It is said that I should use RegisterDeviceNotification to get any additional information. But, if I got it right, it can't be used for serial ports. The DBT_DEVICEARRIVAL and DBT_DEVICEREMOVECOMPLETE events are automatically broadcast to all top-level windows for port devices. Therefore, it is not necessary to call RegisterDeviceNotification for ports, and the function fails if the dbch_devicetype member is DBT_DEVTYP_PORT. So, I am confused. How can I define the com-port of a device, if a get DBT_DEVNODES_CHANGED in WMDEVICECHANGE event?

  Read the article

• TCP Zero Window with no corresponding Window Update

  - by Gandalf

  I am trying to debug a network issue and am using Wireshark and tcpdump to grab packets from my server. I have one client application that is grabbing all my available connections and then holding them, trying to send A LOT of data and essentially causing an unintentional DOS attack. While debugging I notice that I see my server sending "Window Closed" and "Zero Window" TCP packets - but never sending any "Window Update" packets. I am guessing this is why the client never lets go of the connections (it still has more data to send and is waiting). Has anyone ever seen this type of behavior before? Let's not get into the reasons why I haven't set up an iptables rule to limit concurrent connections (yeah I know). I also recently changed the MTU from 1500 to 9000 - could this have such a negative effect? (Linux) Thanks.

  Read the article

• AIX network parameters to close TCP sockets of unplugged devices

  - by ADD Geek

  Hi there We have an AIX box, running what we call in banking "ATM Switch" not the ATM networking switch, but the bank ATM driver. where we have some ATM machines connected to two server processes. The problem is, when we disconnect any of these machines, the netstat -na| grep <port number> command shows that the socket established for this disconnected device is still established, we have to manually send a command from the software to make the socket aware that it is not live anymore. Is there a parameter on tcp level to make this connection aware within a minute or two that this device is not connected anymore? we had the following parameters set with root privileges: no -o tcp_keepidle=1000 no -o tcp_keepcnt=2 no -o tcp_keepintvl=150 no -o tcp_finwait2=100 it was originally having the default values. but even after we changed these parameters and restarted the server processes, the problem was still there.

  Read the article

• TCP failure on Solaris

  - by anurag kohli

  Hi All, I recently ran into a problem where a Solaris server could not establish a TCP socket on port 2126. From a packet capture I see this (note: A is a Solaris server, B is a router): A sends SYN to B B sends SYN, ACK to A Notice A (Solaris) does not acknowledge the SYN from B. Due to the business impact of the problem, I had to reboot the server to fix the problem. That said, I want to know the next time the problem occurs, what can I do to get a root cause (ie before server reboot)? Thanks in advance.

  Read the article

• Several Server Errors (No database connect, can't create TCP/IP socket etc

  - by Tobias Baumeister

  My server stops taking requests on my website today. It works for some time, but then the server just stops working and throws several errors: 500 Internal Server Error Warning: mysql_connect(): Can't create TCP/IP socket (105) in [...] on line 7 Couldn't connect to database. Please try again. mysql_connect(): Host [...] is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' mod_fcgid: can't apply process slot for /var/www/cgi-bin/cgi_wrapper/cgi_wrapper (this is from Error Log) Any ideas what might cause it? operating system is Ubuntu

  Read the article

• How to config DNS onto TCP from UDP

  - by Dante Jiang

  Google DNS (8.8.8.8 and 8.8.4.4) are blocked (or polluted) by all ISPs available to me (and DNS by ISPs just return wrong answers for some sensitive sites!!), and it is said that if we change DNS from UDP onto TCP, the problem can be temporarily solved. My question is: how to config that on Windows 7? The solution provided by the original post: Windows 7 Ultimate DnsApi.dll v6.1.7601.17570 .text:6DC08FC8 8B 46 10 mov eax, [esi+10h] .text:6DC08FCB 89 45 F4 mov [ebp+var_C], eax var_C - 2 85A0: 90 90 90 90 90 -> 33 C0 40 EB 25 85C8: 8B 46 10 -> EB D6 40 I have not figure out how the original solution works so far. It needs to modify the .dll file, and the post provides a .dll after modification. However, I wish there was a solution without this kind of hacking.

  Read the article

• VirtualBox Port Fowarding to Connect to PostgreSQL Database

  - by kliao

  I'm trying to connect to a PostgreSQL database hosted on a Win7 guest from a Win7 host. I've configured security in pg_hba.conf host all all 127.0.0.1/32 md5 host all all 10.0.2.15/32 md5 host all all 192.168.1.6/32 md5 and set the listen_addresses setting in postgresql.conf to '*'. I think I've set up port forwarding correctly as I see: Key: VBoxInternal/Devices/e1000/0/LUN#0/Config/win7_vm1/GuestPort, Value: 5432 Key: VBoxInternal/Devices/e1000/0/LUN#0/Config/win7_vm1/HostPort, Value: 5432 Key: VBoxInternal/Devices/e1000/0/LUN#0/Config/win7_vm1/Protocol, Value: TCP when I call getextradata. This is similar to http://serverfault.com/questions/106168/cant-connect-to-postgresql-on-virtualbox-guest but I'm not sure what I'm doing wrong. In the vbox.log file I see: 00:00:01.019 NAT: set redirect TCP host port 5432 = guest port 5432 @ 10.0.2.15 00:00:01.033 NAT: failed to redirect TCP 5432 = 5432 but I'm not sure how to fix that. Any ideas? Thanks.

  Read the article

• proxy pass domain FROM default apache port 80 TO nginx on another port

  - by user10580

  Im still learning server things so hope the title is descriptive enough. Basically i have sub.domain.com that i want to run on nginx at port 8090. I want to leave apache alone and have it catch all default traffic at port 80. so i am trying something with a virtual name host to proxy pass to sub.domain.com:8090, nothing working yet and go no idea what the right syntax could be. any ideas? most of what i found was to pass TO apache FROM nginx, but i want to the do the opposite. LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so <VirtualHost sub.domain.com:80> ProxyPreserveHost On ProxyRequests Off ServerName sub.domain.com DocumentRoot /home/app/public ServerAlias sub.domain.com proxyPass / http://appname:8090/ (also tried localhost and sub.domain.com) ProxyPassReverse / http://appname:8090/ </VirtualHost> when i do this i get [warn] module proxy_module is already loaded, skippin [warn] module proxy_http_module is already loaded, skipping [error] (EAI 2)Name or service not known: Could not resolve host name sub.domain.com -- ignoring! and yes, the app is working (i have it running on port 80 with another subdomain) and it works at sub.domain.com:8090

  Read the article

• Relation between TCP/IP Keep Alive and HTTP Keep Alive timeout values

  - by Suresh Kumar

  I am trying to understand the relation between TCP/IP and HTTP timeout values. Are these two timeout values different or same? Most Web servers allow users to set the HTTP Keep Alive timeout value through some configuration. How is this value used by the Web servers? is this value just set on the underlying TCP/IP socket i.e is the HTTP Keep Alive timeout and TCP/IP Keep Alive Timeout same? or are they treated differently? My understanding is (maybe incorrect): The Web server uses the default timeout on the underlying TCP socket (i.e. indefinite) and creates Worker thread that counts down the specified HTTP timeout interval. When the Worker thread hits zero, it closes the connection.

  Read the article

• Real benefits of tcp TIME-WAIT and implications in production environment

  - by user64204

  SOME THEORY I've been doing some reading on tcp TIME-WAIT (here and there) and what I read is that it's a value set to 2 x MSL (maximum segment life) which keeps a connection in the "connection table" for a while to guarantee that, "before your allowed to create a connection with the same tuple, all the packets belonging to previous incarnations of that tuple will be dead". Since segments received (apart from SYN under specific circumstances) while a connection is either in TIME-WAIT or no longer existing would be discarded, why not close the connection right away? Q1: Is it because there is less processing involved in dealing with segments from old connections and less processing to create a new connection on the same tuple when in TIME-WAIT (i.e. are there performance benefits)? If the above explanation doesn't stand, the only reason I see the TIME-WAIT being useful would be if a client sends a SYN for a connection before it sends remaining segments for an old connection on the same tuple in which case the receiver would re-open the connection but then get bad segments and and would have to terminate it. Q2: Is this analysis correct? Q3: Are there other benefits to using TIME-WAIT? SOME PRACTICE I've been looking at the munin graphs on a production server that I administrate. Here is one: As you can see there are more connections in TIME-WAIT than ESTABLISHED, around twice as many most of the time, on some occasions four times as many. Q4: Does this have an impact on performance? Q5: If so, is it wise/recommended to reduce the TIME-WAIT value (and what to)? Q6: Is this ratio of TIME-WAIT / ESTABLISHED connections normal? Could this be related to malicious connection attempts?

  Read the article

• Close TCP connection when owner process is already killed

  - by Otiel

  I have a Windows service that - when it starts - opens some WCF services to listen on the 8000 port. It happens that this service crashes sometimes. When it does, the TCP connection is not released, thus causing my service to throw an exception if I try to start it again: AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:8000 Some observations: When running CurrPorts or netstat -ano, I can see that the 8000 port is still in use (in LISTENING state) and is owned by the Process ID XXX that corresponded to my service process ID. But my service has already crashed, and does not appear in the Task Manager anymore. Thus I can't kill the process to free the port! Of course, running taskkill /PID XXX returns: ERROR: The process "XXX" not found. When running CurrPorts or netstat -b, I can see that the process name involved in creating the listening port is System, and not as MyService.exe (whereas it is MyService.exe when my service is running). I tried to use CurrPorts to close the connection, but I always get the following error message: Failed to close one or more TCP connections. Be aware that you must run this tool as admin in order to close TCP connections. (Useless to say, I do run CurrPorts as Administrator...) TCPView is not much help either: the process name associated to the 8000 port is <non-existent>, and doing "End process" or "Close connection" has no effect. I tried to see if there was not a child process associated with the PID XXX using Process Explorer, but no luck here. If I close my service properly (before it crashes), the TCP connection is correctly released. This is normal, as I close the WCF service hosts in the OnStop() event of my service. The only way I found to release the connection is to restart the server (which is not convenient in a production environment as you can guess). Waiting does not help, the TCP connection is never released. How can I close the connection without restarting the Windows server? PS: found some questions extremely similar to mine.

  Read the article

< Previous Page | 6 7 8 9 10 11 12 13 14 15 16 17  | Next Page >