Search Results

Search found 321 results on 13 pages for 'ack'.

Page 3/13 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Is it possible to ack nagios alerts from the terminal on a remote workstation?

    - by cat pants
    I have nagios alerts set up to come through jabber with an http link to ack. Is is possible there is a script I can run from a terminal on a remote workstation that takes the hostname as a parameter and acks the alert? ./ack hostname The benefit, while seemingly mundane, is threefold. First, take http load off nagios. Secondly, nagios http pages can take up to 10-20 seconds to load, so I want to save time there. Thirdly, avoiding slower use of mouse + web interface + firefox/other annoyingly slow browser. Ideally, I would like a script bound to a keyboard shortcut that simply acks the most recent alert. Finally, I want to take the inputs from a joystick, buttons and whatnot, and connect one to a big red button bound to the script so I can just ack the most recent nagios alert by hitting the button lol. (It would be rad too if the button had a screen on the enclosure that showed the text of the alert getting acked lol) Make fun of me all you want, but this is actually something that would be useful to me. If I can save five seconds per alert, and I get 200 alerts per day I need to ack, that's saving me 15 minutes a day. And isn't the whole point of the sysadmin to automate what can be automated? Thanks!

    Read the article

  • My IIS server won't serve SSL sites to some browsers

    - by sbleon
    (Update: This is now cross-posted at http://stackoverflow.com/questions/3355000. This is the more appropriate forum, but StackOverflow gets a lot more traffic.) I've got an IIS 6.0 server that won't serve pages over SSL to some browsers. In Webkit-based browsers on OS X 10.6, I can't load pages at all. In MSIE 8 on Windows XP SP3, I can load pages, but it will sometimes hang downloading images or sending POSTs. Working: Firefox 3.6 (OS X + Windows) Chrome (Windows) Partially Working: MSIE 8 (works sometimes, but hangs up, especially on POSTs) Not Working: Chrome 5 (OS X) Safari 5 (OS X) Mobile Safari (iOS 4) On OS X (the easiest platform for me to test on), Chrome and Firefox both negotiate the same TLS Cipher, but Chrome hangs on or after the post-negotiation handshake. Chrome packet capture (via ssldump): 1 1 0.0485 (0.0485) C>S Handshake ClientHello Version 3.1 cipher suites Unknown value 0xc00a Unknown value 0xc009 Unknown value 0xc007 Unknown value 0xc008 Unknown value 0xc013 Unknown value 0xc014 Unknown value 0xc011 Unknown value 0xc012 Unknown value 0xc004 Unknown value 0xc005 Unknown value 0xc002 Unknown value 0xc003 Unknown value 0xc00e Unknown value 0xc00f Unknown value 0xc00c Unknown value 0xc00d Unknown value 0x2f TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 Unknown value 0x35 TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0x32 Unknown value 0x33 Unknown value 0x38 Unknown value 0x39 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA compression methods NULL 1 2 0.3106 (0.2620) S>C Handshake ServerHello Version 3.1 session_id[32]= bb 0e 00 00 7a 7e 07 50 5e 78 48 cf 43 5a f7 4d d2 ed 72 8f ff 1d 9e 74 66 74 03 b3 bb 92 8d eb cipherSuite TLS_RSA_WITH_RC4_128_MD5 compressionMethod NULL Certificate ServerHelloDone 1 3 0.3196 (0.0090) C>S Handshake ClientKeyExchange 1 4 0.3197 (0.0000) C>S ChangeCipherSpec 1 5 0.3197 (0.0000) C>S Handshake [hang, no more data transmitted] Firefox packet capture: 1 1 0.0485 (0.0485) C>S Handshake ClientHello Version 3.1 resume [32]= 14 03 00 00 4e 28 de aa da 7a 25 87 25 32 f3 a7 ae 4c 2d a0 e4 57 cc dd d7 0e d7 82 19 f7 8f b9 cipher suites Unknown value 0xff Unknown value 0xc00a Unknown value 0xc014 Unknown value 0x88 Unknown value 0x87 Unknown value 0x39 Unknown value 0x38 Unknown value 0xc00f Unknown value 0xc005 Unknown value 0x84 Unknown value 0x35 Unknown value 0xc007 Unknown value 0xc009 Unknown value 0xc011 Unknown value 0xc013 Unknown value 0x45 Unknown value 0x44 Unknown value 0x33 Unknown value 0x32 Unknown value 0xc00c Unknown value 0xc00e Unknown value 0xc002 Unknown value 0xc004 Unknown value 0x96 Unknown value 0x41 TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA Unknown value 0x2f Unknown value 0xc008 Unknown value 0xc012 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xc00d Unknown value 0xc003 Unknown value 0xfeff TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL 1 2 0.0983 (0.0497) S>C Handshake ServerHello Version 3.1 session_id[32]= 14 03 00 00 4e 28 de aa da 7a 25 87 25 32 f3 a7 ae 4c 2d a0 e4 57 cc dd d7 0e d7 82 19 f7 8f b9 cipherSuite TLS_RSA_WITH_RC4_128_MD5 compressionMethod NULL 1 3 0.0983 (0.0000) S>C ChangeCipherSpec 1 4 0.0983 (0.0000) S>C Handshake 1 5 0.1019 (0.0035) C>S ChangeCipherSpec 1 6 0.1019 (0.0000) C>S Handshake 1 7 0.1019 (0.0000) C>S application_data 1 8 0.2460 (0.1440) S>C application_data 1 9 0.3108 (0.0648) S>C application_data 1 10 0.3650 (0.0542) S>C application_data 1 11 0.4188 (0.0537) S>C application_data 1 12 0.4580 (0.0392) S>C application_data 1 13 0.4831 (0.0251) S>C application_data [etc] Update: Here's a Wireshark capture from the server end. What's going on with those two much-delayed RST packets? Is that just IIS terminating what it perceives as a non-responsive connection? 19 10.129450 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=699250189 TSER=0 20 10.129517 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 21 10.168596 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=699250189 TSER=0 22 10.172950 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Client Hello 23 10.173267 10.100.xxx.xx 67.249.xxx.xxx TCP [TCP segment of a reassembled PDU] 24 10.173297 10.100.xxx.xx 67.249.xxx.xxx TCP [TCP segment of a reassembled PDU] 25 10.385180 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=148 Ack=2897 Win=524280 Len=0 TSV=699250191 TSER=163006 26 10.385235 10.100.xxx.xx 67.249.xxx.xxx TLSv1 Server Hello, Certificate, Server Hello Done 27 10.424682 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=148 Ack=4215 Win=524280 Len=0 TSV=699250192 TSER=163008 28 10.435245 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Client Key Exchange 29 10.438522 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Change Cipher Spec 30 10.438553 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [ACK] Seq=4215 Ack=421 Win=65115 Len=0 TSV=163008 TSER=699250192 31 10.449036 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Encrypted Handshake Message 32 10.580652 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [ACK] Seq=4215 Ack=458 Win=65078 Len=0 TSV=163010 TSER=699250192 7312 57.315338 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50644 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 19531 142.316425 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [RST, ACK] Seq=4215 Ack=458 Win=0 Len=0

    Read the article

  • My IIS server won't serve SSL sites to some browsers

    - by sbleon
    (Update: This is now cross-posted at http://stackoverflow.com/questions/3355000. This is the more appropriate forum, but StackOverflow gets a lot more traffic.) I've got an IIS 6.0 server that won't serve pages over SSL to some browsers. In Webkit-based browsers on OS X 10.6, I can't load pages at all. In MSIE 8 on Windows XP SP3, I can load pages, but it will sometimes hang downloading images or sending POSTs. Working: Firefox 3.6 (OS X + Windows) Chrome (Windows) Partially Working: MSIE 8 (works sometimes, but hangs up, especially on POSTs) Not Working: Chrome 5 (OS X) Safari 5 (OS X) Mobile Safari (iOS 4) On OS X (the easiest platform for me to test on), Chrome and Firefox both negotiate the same TLS Cipher, but Chrome hangs on or after the post-negotiation handshake. Chrome packet capture (via ssldump): 1 1 0.0485 (0.0485) C>S Handshake ClientHello Version 3.1 cipher suites Unknown value 0xc00a Unknown value 0xc009 Unknown value 0xc007 Unknown value 0xc008 Unknown value 0xc013 Unknown value 0xc014 Unknown value 0xc011 Unknown value 0xc012 Unknown value 0xc004 Unknown value 0xc005 Unknown value 0xc002 Unknown value 0xc003 Unknown value 0xc00e Unknown value 0xc00f Unknown value 0xc00c Unknown value 0xc00d Unknown value 0x2f TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 Unknown value 0x35 TLS_RSA_WITH_3DES_EDE_CBC_SHA Unknown value 0x32 Unknown value 0x33 Unknown value 0x38 Unknown value 0x39 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA compression methods NULL 1 2 0.3106 (0.2620) S>C Handshake ServerHello Version 3.1 session_id[32]= bb 0e 00 00 7a 7e 07 50 5e 78 48 cf 43 5a f7 4d d2 ed 72 8f ff 1d 9e 74 66 74 03 b3 bb 92 8d eb cipherSuite TLS_RSA_WITH_RC4_128_MD5 compressionMethod NULL Certificate ServerHelloDone 1 3 0.3196 (0.0090) C>S Handshake ClientKeyExchange 1 4 0.3197 (0.0000) C>S ChangeCipherSpec 1 5 0.3197 (0.0000) C>S Handshake [hang, no more data transmitted] Firefox packet capture: 1 1 0.0485 (0.0485) C>S Handshake ClientHello Version 3.1 resume [32]= 14 03 00 00 4e 28 de aa da 7a 25 87 25 32 f3 a7 ae 4c 2d a0 e4 57 cc dd d7 0e d7 82 19 f7 8f b9 cipher suites Unknown value 0xff Unknown value 0xc00a Unknown value 0xc014 Unknown value 0x88 Unknown value 0x87 Unknown value 0x39 Unknown value 0x38 Unknown value 0xc00f Unknown value 0xc005 Unknown value 0x84 Unknown value 0x35 Unknown value 0xc007 Unknown value 0xc009 Unknown value 0xc011 Unknown value 0xc013 Unknown value 0x45 Unknown value 0x44 Unknown value 0x33 Unknown value 0x32 Unknown value 0xc00c Unknown value 0xc00e Unknown value 0xc002 Unknown value 0xc004 Unknown value 0x96 Unknown value 0x41 TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA Unknown value 0x2f Unknown value 0xc008 Unknown value 0xc012 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA Unknown value 0xc00d Unknown value 0xc003 Unknown value 0xfeff TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL 1 2 0.0983 (0.0497) S>C Handshake ServerHello Version 3.1 session_id[32]= 14 03 00 00 4e 28 de aa da 7a 25 87 25 32 f3 a7 ae 4c 2d a0 e4 57 cc dd d7 0e d7 82 19 f7 8f b9 cipherSuite TLS_RSA_WITH_RC4_128_MD5 compressionMethod NULL 1 3 0.0983 (0.0000) S>C ChangeCipherSpec 1 4 0.0983 (0.0000) S>C Handshake 1 5 0.1019 (0.0035) C>S ChangeCipherSpec 1 6 0.1019 (0.0000) C>S Handshake 1 7 0.1019 (0.0000) C>S application_data 1 8 0.2460 (0.1440) S>C application_data 1 9 0.3108 (0.0648) S>C application_data 1 10 0.3650 (0.0542) S>C application_data 1 11 0.4188 (0.0537) S>C application_data 1 12 0.4580 (0.0392) S>C application_data 1 13 0.4831 (0.0251) S>C application_data [etc] Update: Here's a Wireshark capture from the server end. What's going on with those two much-delayed RST packets? Is that just IIS terminating what it perceives as a non-responsive connection? 19 10.129450 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=699250189 TSER=0 20 10.129517 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 21 10.168596 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=699250189 TSER=0 22 10.172950 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Client Hello 23 10.173267 10.100.xxx.xx 67.249.xxx.xxx TCP [TCP segment of a reassembled PDU] 24 10.173297 10.100.xxx.xx 67.249.xxx.xxx TCP [TCP segment of a reassembled PDU] 25 10.385180 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=148 Ack=2897 Win=524280 Len=0 TSV=699250191 TSER=163006 26 10.385235 10.100.xxx.xx 67.249.xxx.xxx TLSv1 Server Hello, Certificate, Server Hello Done 27 10.424682 67.249.xxx.xxx 10.100.xxx.xx TCP 50653 > https [ACK] Seq=148 Ack=4215 Win=524280 Len=0 TSV=699250192 TSER=163008 28 10.435245 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Client Key Exchange 29 10.438522 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Change Cipher Spec 30 10.438553 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [ACK] Seq=4215 Ack=421 Win=65115 Len=0 TSV=163008 TSER=699250192 31 10.449036 67.249.xxx.xxx 10.100.xxx.xx TLSv1 Encrypted Handshake Message 32 10.580652 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [ACK] Seq=4215 Ack=458 Win=65078 Len=0 TSV=163010 TSER=699250192 7312 57.315338 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50644 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 19531 142.316425 10.100.xxx.xx 67.249.xxx.xxx TCP https > 50653 [RST, ACK] Seq=4215 Ack=458 Win=0 Len=0

    Read the article

  • MySQL hangs if connection comes from outside the LAN

    - by Subito
    I have a MySQL Server operating just fine if I access him from his local LAN (192.168.100.0/24). If I try to access hin from another LAN (192.168.113.0/24 in this case) it hangs for a really long time before delivering the result. SHOW PROCESSLIST; shows this process in Sleep, State empty. If I strace -p this process I get the following Output (23512 is the PID of the corresponding mysqld process): Process 23512 attached - interrupt to quit restart_syscall(<... resuming interrupted call ...>) = 1 fcntl(10, F_GETFL) = 0x2 (flags O_RDWR) fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK) = 0 accept(10, {sa_family=AF_INET, sin_port=htons(51696), sin_addr=inet_addr("192.168.113.4")}, [16]) = 33 fcntl(10, F_SETFL, O_RDWR) = 0 rt_sigaction(SIGCHLD, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x7f9ce7ca34f0}, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x7f9ce7ca34f0}, ) = 0 getpeername(33, {sa_family=AF_INET, sin_port=htons(51696), sin_addr=inet_addr("192.168.113.4")}, [16]) = 0 getsockname(33, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("192.168.100.190")}, [16]) = 0 open("/etc/hosts.allow", O_RDONLY) = 64 fstat(64, {st_mode=S_IFREG|0644, st_size=580, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9ce9839000 read(64, "# /etc/hosts.allow: list of host"..., 4096) = 580 read(64, "", 4096) = 0 close(64) = 0 munmap(0x7f9ce9839000, 4096) = 0 open("/etc/hosts.deny", O_RDONLY) = 64 fstat(64, {st_mode=S_IFREG|0644, st_size=880, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9ce9839000 read(64, "# /etc/hosts.deny: list of hosts"..., 4096) = 880 read(64, "", 4096) = 0 close(64) = 0 munmap(0x7f9ce9839000, 4096) = 0 getsockname(33, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("192.168.100.190")}, [16]) = 0 fcntl(33, F_SETFL, O_RDONLY) = 0 fcntl(33, F_GETFL) = 0x2 (flags O_RDWR) setsockopt(33, SOL_SOCKET, SO_RCVTIMEO, "\36\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0 setsockopt(33, SOL_SOCKET, SO_SNDTIMEO, "<\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0 fcntl(33, F_SETFL, O_RDWR|O_NONBLOCK) = 0 setsockopt(33, SOL_IP, IP_TOS, [8], 4) = 0 setsockopt(33, SOL_TCP, TCP_NODELAY, [1], 4) = 0 futex(0x7f9cea5c9564, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f9cea5c9560, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 futex(0x7f9cea5c6fe0, FUTEX_WAKE_PRIVATE, 1) = 1 poll([{fd=10, events=POLLIN}, {fd=12, events=POLLIN}], 2, -1) = 1 ([{fd=10, revents=POLLIN}]) fcntl(10, F_GETFL) = 0x2 (flags O_RDWR) fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK) = 0 accept(10, {sa_family=AF_INET, sin_port=htons(51697), sin_addr=inet_addr("192.168.113.4")}, [16]) = 31 fcntl(10, F_SETFL, O_RDWR) = 0 rt_sigaction(SIGCHLD, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x7f9ce7ca34f0}, {SIG_DFL, [CHLD], SA_RESTORER|SA_RESTART, 0x7f9ce7ca34f0}, ) = 0 getpeername(31, {sa_family=AF_INET, sin_port=htons(51697), sin_addr=inet_addr("192.168.113.4")}, [16]) = 0 getsockname(31, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("192.168.100.190")}, [16]) = 0 open("/etc/hosts.allow", O_RDONLY) = 33 fstat(33, {st_mode=S_IFREG|0644, st_size=580, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9ce9839000 read(33, "# /etc/hosts.allow: list of host"..., 4096) = 580 read(33, "", 4096) = 0 close(33) = 0 munmap(0x7f9ce9839000, 4096) = 0 open("/etc/hosts.deny", O_RDONLY) = 33 fstat(33, {st_mode=S_IFREG|0644, st_size=880, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9ce9839000 read(33, "# /etc/hosts.deny: list of hosts"..., 4096) = 880 read(33, "", 4096) = 0 close(33) = 0 munmap(0x7f9ce9839000, 4096) = 0 getsockname(31, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("192.168.100.190")}, [16]) = 0 fcntl(31, F_SETFL, O_RDONLY) = 0 fcntl(31, F_GETFL) = 0x2 (flags O_RDWR) setsockopt(31, SOL_SOCKET, SO_RCVTIMEO, "\36\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0 setsockopt(31, SOL_SOCKET, SO_SNDTIMEO, "<\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0 fcntl(31, F_SETFL, O_RDWR|O_NONBLOCK) = 0 setsockopt(31, SOL_IP, IP_TOS, [8], 4) = 0 setsockopt(31, SOL_TCP, TCP_NODELAY, [1], 4) = 0 futex(0x7f9cea5c9564, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f9cea5c9560, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 futex(0x7f9cea5c6fe0, FUTEX_WAKE_PRIVATE, 1) = 1 poll([{fd=10, events=POLLIN}, {fd=12, events=POLLIN}], 2, -1^C <unfinished ...> Process 23512 detached This output repeats itself until the answer gets send. It could take up to 15 Minutes until the request gets served. In the local LAN its a matter of Milliseconds. Why is this and how can I debug this further? [Edit] tcpdump shows a ton of this: 14:49:44.103107 IP cassandra-test.mysql > 192.168.X.6.64626: Flags [S.], seq 1434117703, ack 1793610733, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 14:49:44.135187 IP 192.168.X.6.64625 > cassandra-test.mysql: Flags [P.], seq 106:145, ack 182, win 4345, length 39 14:49:44.135293 IP cassandra-test.mysql > 192.168.X.6.64625: Flags [P.], seq 182:293, ack 145, win 115, length 111 14:49:44.167025 IP 192.168.X.6.64624 > cassandra-test.mysql: Flags [.], ack 444, win 4280, length 0 14:49:44.168933 IP 192.168.X.6.64626 > cassandra-test.mysql: Flags [.], ack 1, win 4390, length 0 14:49:44.169088 IP cassandra-test.mysql > 192.168.X.6.64626: Flags [P.], seq 1:89, ack 1, win 115, length 88 14:49:44.169672 IP 192.168.X.6.64625 > cassandra-test.mysql: Flags [P.], seq 145:171, ack 293, win 4317, length 26 14:49:44.169726 IP cassandra-test.mysql > 192.168.X.6.64625: Flags [P.], seq 293:419, ack 171, win 115, length 126 14:49:44.275111 IP 192.168.X.6.64626 > cassandra-test.mysql: Flags [P.], seq 1:74, ack 89, win 4368, length 73 14:49:44.275131 IP cassandra-test.mysql > 192.168.X.6.64626: Flags [.], ack 74, win 115, length 0 14:49:44.275149 IP 192.168.X.6.64625 > cassandra-test.mysql: Flags [P.], seq 171:180, ack 419, win 4286, length 9 14:49:44.275189 IP cassandra-test.mysql > 192.168.X.6.64626: Flags [P.], seq 89:100, ack 74, win 115, length 11 14:49:44.275264 IP 192.168.X.6.64625 > cassandra-test.mysql: Flags [P.], seq 180:185, ack 419, win 4286, length 5 14:49:44.275281 IP cassandra-test.mysql > 192.168.X.6.64625: Flags [.], ack 185, win 115, length 0 14:49:44.275295 IP cassandra-test.mysql > 192.168.X.6.64625: Flags [F.], seq 419, ack 185, win 115, length 0 14:49:44.275650 IP 192.168.X.6.64625 > cassandra-test.mysql: Flags [F.], seq 185, ack 419, win 4286, length 0 14:49:44.275660 IP cassandra-test.mysql > 192.168.X.6.64625: Flags [.], ack 186, win 115, length 0 14:49:44.275910 IP 192.168.X.6.64627 > cassandra-test.mysql: Flags [S], seq 2336421549, win 8192, options [mss 1351,nop,wscale 2,nop,nop,sackOK], length 0 14:49:44.275921 IP cassandra-test.mysql > 192.168.X.6.64627: Flags [S.], seq 3289359778, ack 2336421550, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

    Read the article

  • How it was detected if last ACK lost in TCP connection termination procedure?

    - by sonali
    In TCP Connection Termination, when client enters in TIME_WAIT state means the client waits for a period of time equal to double the maximum segment life (MSL) time, to ensure the ACK it sent was received. (I read above from a book computer networking by kurose and also given in following URL http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm ) But how it was detected if last ACK(send by client as a response to server FIN) lost?

    Read the article

  • How can I read pcap files in a friendly format?

    - by Tony
    a simple cat on the pcap file looks terrible: $cat tcp_dump.pcap ?ò????YVJ? JJ ?@@.?E<??@@ ?CA??qe?U?????h? .Ceh?YVJ?? JJ ?@@.?E<??@@ CA??qe?U?????z? .ChV?YVJ$?JJ ?@@.?E<-/@@A?CA??9????F???A&? .Ck??YVJgeJJ@@.??#3E<@3{n??9CA??P???F???<K? ??`.Ck??YVJgeBB ?@@.?E4-0@@AFCA??9????F?P????? .Ck???`?YVJ?""@@.??#3E?L@3?I??9CA??P???F????? ???.Ck?220-rly-da03.mx etc. I tried to make it prettier with: sudo tcpdump -ttttnnr tcp_dump.pcap reading from file tcp_dump.pcap, link-type EN10MB (Ethernet) 2009-07-09 20:57:40.819734 IP 67.23.28.65.49237 > 216.239.113.101.25: S 2535121895:2535121895(0) win 5840 <mss 1460,sackOK,timestamp 776168808 0,nop,wscale 5> 2009-07-09 20:57:43.819905 IP 67.23.28.65.49237 > 216.239.113.101.25: S 2535121895:2535121895(0) win 5840 <mss 1460,sackOK,timestamp 776169558 0,nop,wscale 5> 2009-07-09 20:57:47.248100 IP 67.23.28.65.42385 > 205.188.159.57.25: S 2644526720:2644526720(0) win 5840 <mss 1460,sackOK,timestamp 776170415 0,nop,wscale 5> 2009-07-09 20:57:47.288103 IP 205.188.159.57.25 > 67.23.28.65.42385: S 1358829769:1358829769(0) ack 2644526721 win 5792 <mss 1460,sackOK,timestamp 4292123488 776170415,nop,wscale 2> 2009-07-09 20:57:47.288103 IP 67.23.28.65.42385 > 205.188.159.57.25: . ack 1 win 183 <nop,nop,timestamp 776170425 4292123488> 2009-07-09 20:57:47.368107 IP 205.188.159.57.25 > 67.23.28.65.42385: P 1:481(480) ack 1 win 1448 <nop,nop,timestamp 4292123568 776170425> 2009-07-09 20:57:47.368107 IP 67.23.28.65.42385 > 205.188.159.57.25: . ack 481 win 216 <nop,nop,timestamp 776170445 4292123568> 2009-07-09 20:57:47.368107 IP 67.23.28.65.42385 > 205.188.159.57.25: P 1:18(17) ack 481 win 216 <nop,nop,timestamp 776170445 4292123568> 2009-07-09 20:57:47.404109 IP 205.188.159.57.25 > 67.23.28.65.42385: . ack 18 win 1448 <nop,nop,timestamp 4292123606 776170445> 2009-07-09 20:57:47.404109 IP 205.188.159.57.25 > 67.23.28.65.42385: P 481:536(55) ack 18 win 1448 <nop,nop,timestamp 4292123606 776170445> 2009-07-09 20:57:47.404109 IP 67.23.28.65.42385 > 205.188.159.57.25: P 18:44(26) ack 536 win 216 <nop,nop,timestamp 776170454 4292123606> 2009-07-09 20:57:47.444112 IP 205.188.159.57.25 > 67.23.28.65.42385: P 536:581(45) ack 44 win 1448 <nop,nop,timestamp 4292123644 776170454> 2009-07-09 20:57:47.484114 IP 67.23.28.65.42385 > 205.188.159.57.25: . ack 581 win 216 <nop,nop,timestamp 776170474 4292123644> 2009-07-09 20:57:47.616121 IP 67.23.28.65.42385 > 205.188.159.57.25: P 44:50(6) ack 581 win 216 <nop,nop,timestamp 776170507 4292123644> 2009-07-09 20:57:47.652123 IP 205.188.159.57.25 > 67.23.28.65.42385: P 581:589(8) ack 50 win 1448 <nop,nop,timestamp 4292123855 776170507> 2009-07-09 20:57:47.652123 IP 67.23.28.65.42385 > 205.188.159.57.25: . ack 589 win 216 <nop,nop,timestamp 776170516 4292123855> 2009-07-09 20:57:47.652123 IP 67.23.28.65.42385 > 205.188.159.57.25: P 50:56(6) ack 589 win 216 <nop,nop,timestamp 776170516 4292123855> 2009-07-09 20:57:47.652123 IP 67.23.28.65.42385 > 205.188.159.57.25: F 56:56(0) ack 589 win 216 <nop,nop,timestamp 776170516 4292123855> 2009-07-09 20:57:47.668124 IP 67.23.28.65.49239 > 216.239.113.101.25: S 2642380481:2642380481(0) win 5840 <mss 1460,sackOK,timestamp 776170520 0,nop,wscale 5> 2009-07-09 20:57:47.692126 IP 205.188.159.57.25 > 67.23.28.65.42385: P 589:618(29) ack 57 win 1448 <nop,nop,timestamp 4292123893 776170516> 2009-07-09 20:57:47.692126 IP 67.23.28.65.42385 > 205.188.159.57.25: R 2644526777:2644526777(0) win 0 2009-07-09 20:57:47.692126 IP 205.188.159.57.25 > 67.23.28.65.42385: F 618:618(0) ack 57 win 1448 <nop,nop,timestamp 4292123893 776170516> 2009-07-09 20:57:47.692126 IP 67.23.28.65.42385 > 205.188.159.57.25: R 2644526777:2644526777(0) win 0 Well...that is much prettier but it doesn't show the actual messages. I can actually extract more information just viewing the RAW file. What is the best ( and preferably easiest) way to just view all the contents of the pcap file? UPDATE Thanks to the responses below, I made some progress. Here is what it looks like now: tcpdump -qns 0 -A -r blah.pcap 20:57:47.368107 IP 205.188.159.57.25 > 67.23.28.65.42385: tcp 480 0x0000: 4500 0214 834c 4000 3306 f649 cdbc 9f39 [email protected] 0x0010: 4317 1c41 0019 a591 50fe 18ca 9da0 4681 C..A....P.....F. 0x0020: 8018 05a8 848f 0000 0101 080a ffd4 9bb0 ................ 0x0030: 2e43 6bb9 3232 302d 726c 792d 6461 3033 .Ck.220-rly-da03 0x0040: 2e6d 782e 616f 6c2e 636f 6d20 4553 4d54 .mx.aol.com.ESMT 0x0050: 5020 6d61 696c 5f72 656c 6179 5f69 6e2d P.mail_relay_in- 0x0060: 6461 3033 2e34 3b20 5468 752c 2030 3920 da03.4;.Thu,.09. 0x0070: 4a75 6c20 3230 3039 2031 363a 3537 3a34 Jul.2009.16:57:4 0x0080: 3720 2d30 3430 300d 0a32 3230 2d41 6d65 7.-0400..220-Ame 0x0090: 7269 6361 204f 6e6c 696e 6520 2841 4f4c rica.Online.(AOL 0x00a0: 2920 616e 6420 6974 7320 6166 6669 6c69 ).and.its.affili 0x00b0: 6174 6564 2063 6f6d 7061 6e69 6573 2064 ated.companies.d etc. This looks good, but it still makes the actual message on the right difficult to read. Is there a way to view those messages in a more friendly way? UPDATE This made it pretty: tcpick -C -yP -r tcp_dump.pcap Thanks!

    Read the article

  • Dlink DWA-556 Access point fails to start on 2.6.35-25 while 2.6.35-24 works. How can I do this with >2.6.35-24?

    - by Azendale
    I'm using hostapd to run an access point with a Dlink DWA-556 wireless N card. However, I can no longer get it to start when I use kernels greater than 2.6.35-24. Here's a log where I ran the uname -a&&hostapd -c <configfile> on the different kernel versions. Linux erikbandersen 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 GNU/Linux Configuration file: hostapd.conf ctrl_interface_group=0 Opening raw packet socket for ifindex 248 BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf nl80211: Added 802.11b mode based on 802.11g information HT40: control channel: 2 secondary channel: 6 RATE[0] rate=10 flags=0x2 RATE[1] rate=20 flags=0x6 RATE[2] rate=55 flags=0x6 RATE[3] rate=110 flags=0x6 RATE[4] rate=60 flags=0x0 RATE[5] rate=90 flags=0x0 RATE[6] rate=120 flags=0x0 RATE[7] rate=180 flags=0x0 RATE[8] rate=240 flags=0x0 RATE[9] rate=360 flags=0x0 RATE[10] rate=480 flags=0x0 RATE[11] rate=540 flags=0x0 Passive scanning not supported Mode: IEEE 802.11g Channel: 2 Frequency: 2417 MHz Flushing old station entries Deauthenticate all stations Using interface wlan1 with hwaddr 1c:bd:b9:d5:e8:3c and ssid 'erikbandersen.com/freewifi' wlan1: Setup of interface done. MGMT (TX callback) ACK Malformed netlink message: len=436 left=256 plen=420 256 extra bytes in the end of netlink message MGMT (TX callback) ACK mgmt::proberesp cb MGMT (TX callback) ACK mgmt::proberesp cb MGMT (TX callback) ACK mgmt::proberesp cb mgmt::auth authentication: STA=3c:4a:92:0e:41:2f auth_alg=0 auth_transaction=1 status_code=0 wep=0 New STA wlan1: STA 3c:4a:92:0e:41:2f IEEE 802.11: authentication OK (open system) wlan1: STA 3c:4a:92:0e:41:2f MLME: MLME-AUTHENTICATE.indication(3c:4a:92:0e:41:2f, OPEN_SYSTEM) wlan1: STA 3c:4a:92:0e:41:2f MLME: MLME-DELETEKEYS.request(3c:4a:92:0e:41:2f) authentication reply: STA=3c:4a:92:0e:41:2f auth_alg=0 auth_transaction=2 resp=0 (IE len=0) MGMT (TX callback) ACK mgmt::auth cb wlan1: STA 3c:4a:92:0e:41:2f IEEE 802.11: authenticated mgmt::assoc_req association request: STA=3c:4a:92:0e:41:2f capab_info=0x421 listen_interval=10 Validating WMM IE: OUI 00:50:f2 OUI type 2 OUI sub-type 0 version 1 QoS info 0x0 HT: STA 3c:4a:92:0e:41:2f HT Capabilities Info: 0x102c handle_assoc STA 3c:4a:92:0e:41:2f - no greenfield, num of non-gf stations 1 handle_assoc STA 3c:4a:92:0e:41:2f - 20 MHz HT, num of 20MHz HT STAs 1 hostapd_ht_operation_update current operation mode=0x0 hostapd_ht_operation_update new operation mode=0x7 changes=2 new AID 1 wlan1: STA 3c:4a:92:0e:41:2f IEEE 802.11: association OK (aid 1) MGMT (TX callback) ACK mgmt::assoc_resp cb wlan1: STA 3c:4a:92:0e:41:2f IEEE 802.11: associated (aid 1) wlan1: STA 3c:4a:92:0e:41:2f MLME: MLME-ASSOCIATE.indication(3c:4a:92:0e:41:2f) wlan1: STA 3c:4a:92:0e:41:2f MLME: MLME-DELETEKEYS.request(3c:4a:92:0e:41:2f) wlan1: STA 3c:4a:92:0e:41:2f RADIUS: starting accounting session 4DAC8224-00000000 MGMT (TX callback) ACK mgmt::action cb MGMT (TX callback) ACK mgmt::proberesp cb MGMT (TX callback) ACK mgmt::proberesp cb MGMT (TX callback) ACK mgmt::proberesp cb MGMT (TX callback) ACK mgmt::proberesp cb MGMT (TX callback) ACK mgmt::proberesp cb Signal 2 received - terminating wlan1: STA 3c:4a:92:0e:41:2f MLME: MLME-DEAUTHENTICATE.indication(3c:4a:92:0e:41:2f, 1) wlan1: STA 3c:4a:92:0e:41:2f MLME: MLME-DELETEKEYS.request(3c:4a:92:0e:41:2f) Removing station 3c:4a:92:0e:41:2f hostapd_ht_operation_update current operation mode=0x7 hostapd_ht_operation_update new operation mode=0x0 changes=2 Flushing old station entries Deauthenticate all stations . Linux erikbandersen 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux Configuration file: hostapd.conf ctrl_interface_group=0 Opening raw packet socket for ifindex 248 BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf nl80211: Added 802.11b mode based on 802.11g information Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=2 freq=2417 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=3 freq=2422 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=4 freq=2427 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=5 freq=2432 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=6 freq=2437 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=7 freq=2442 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=8 freq=2447 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=9 freq=2452 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=10 freq=2457 MHz max_tx_power=27 dBm Allowed channel: mode=1 chan=11 freq=2462 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=1 freq=2412 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=2 freq=2417 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=3 freq=2422 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=4 freq=2427 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=5 freq=2432 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=6 freq=2437 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=7 freq=2442 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=8 freq=2447 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=9 freq=2452 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=10 freq=2457 MHz max_tx_power=27 dBm Allowed channel: mode=0 chan=11 freq=2462 MHz max_tx_power=27 dBm HT40: control channel: 2 secondary channel: 6 RATE[0] rate=10 flags=0x2 RATE[1] rate=20 flags=0x6 RATE[2] rate=55 flags=0x6 RATE[3] rate=110 flags=0x6 RATE[4] rate=60 flags=0x0 RATE[5] rate=90 flags=0x0 RATE[6] rate=120 flags=0x0 RATE[7] rate=180 flags=0x0 RATE[8] rate=240 flags=0x0 RATE[9] rate=360 flags=0x0 RATE[10] rate=480 flags=0x0 RATE[11] rate=540 flags=0x0 Passive scanning not supported Mode: IEEE 802.11g Channel: 2 Frequency: 2417 MHz Could not set channel for kernel driver wlan1: Unable to setup interface. My wireless card is listed as 02:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01) by lspci. Am I doing it wrong and there's a new way of doing it? I'm holding off upgrading to Natty because of this. What changed between the versions that would cause this? Should I report it as a bug?

    Read the article

  • SSH not working over IPSec tunnel (Strongswan)

    - by PattPatel
    I configured a small network on a cloud virtual machine. This virtual machine has a static IP address assigned to eth0 interface that I'll call $EXTIP. mydomain.com points to $EXTIP. Inside, I have some linux containers, that get their ip through DHCP in the Subnet 10.0.0.0/24 (i called the virtual interface nat ). They run some services that can be reached through DNAT. Then I wanted to connect to these containers through an IPSec tunnel, so I configured StrongSwan. ipsec.conf: conn %default dpdaction=none rekey=no conn remote keyexchange=ikev2 ike=######## left=[$EXTIP] leftsubnet=10.0.1.0/24,10.0.0.0/24 leftauth=pubkey lefthostaccess=yes leftcert=########.pem leftfirewall=yes leftid="#########" right=%any rightsourceip=10.0.1.0/24 rightauth=######## rightid=%any rightsendcert=never eap_identity=%any auto=add type=tunnel Everything works fine, IPSec clients get IPs of the 10.0.1.0/24 subnet and can reach the containers subnet. My problem is that I'm not able to get SSH connections over the tunnel. It simply does not work, ssh client does not produce any output. Sniffing with tcpdump gives: tcpdump: 09:50:29.648206 ARP, Request who-has 10.0.0.1 tell mydomain.com, length 28 09:50:29.648246 ARP, Reply 10.0.0.1 is-at 00:ff:aa:00:00:01 (oui Unknown), length 28 09:50:29.648253 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [S], seq 4007849772, win 29200, options [mss 1460,sackOK,TS val 1151153 ecr 0,nop,wscale 7], length 0 09:50:29.648296 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [S.], seq 2809522632, ack 4007849773, win 14480, options [mss 1460,sackOK,TS val 11482992 ecr 1151153,nop,wscale 6], length 0 09:50:29.677225 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 2809522633, win 229, options [nop,nop,TS val 1151162 ecr 11482992], length 0 09:50:29.679370 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [P.], seq 0:23, ack 1, win 229, options [nop,nop,TS val 1151162 ecr 11482992], length 23 09:50:29.679403 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], ack 24, win 227, options [nop,nop,TS val 11483002 ecr 1151162], length 0 09:50:29.684337 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1:32, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 31 09:50:29.685471 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 32:1480, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 1448 09:50:29.685519 IP mydomain.com > 10.0.0.1: ICMP mydomain.com unreachable - need to frag (mtu 1422), length 556 09:50:29.685567 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 32:1402, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 1370 09:50:29.685572 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], seq 1402:1480, ack 24, win 227, options [nop,nop,TS val 11483003 ecr 1151162], length 78 09:50:29.714601 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 32, win 229, options [nop,nop,TS val 1151173 ecr 11483003], length 0 09:50:29.714642 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1480:1600, ack 24, win 227, options [nop,nop,TS val 11483012 ecr 1151173], length 120 09:50:29.723649 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [P.], seq 1393:1959, ack 32, win 229, options [nop,nop,TS val 1151174 ecr 11483003], length 566 09:50:29.723677 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [.], ack 24, win 227, options [nop,nop,TS val 11483015 ecr 1151173,nop,nop,sack 1 {1394:1960}], length 0 09:50:29.725688 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 1480, win 251, options [nop,nop,TS val 1151177 ecr 11483003], length 0 09:50:29.952394 IP 10.0.0.1.ssh > 10.0.1.2.54869: Flags [P.], seq 1480:1600, ack 24, win 227, options [nop,nop,TS val 11483084 ecr 1151173,nop,nop,sack 1 {1394:1960}], length 120 09:50:29.981056 IP mydomain.com.54869 > 10.0.0.1.ssh: Flags [.], ack 1600, win 251, options [nop,nop,TS val 1151253 ecr 11483084,nop,nop,sack 1 {1480:1600}], length 0 If you need it this is my iptables configuration file: iptables: *filter :INPUT ACCEPT [144:9669] :FORWARD DROP [0:0] :OUTPUT ACCEPT [97:15649] :interfacce-trusted - [0:0] :porte-trusted - [0:0] -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j interfacce-trusted -A FORWARD -j porte-trusted -A FORWARD -j REJECT --reject-with icmp-host-unreachable -A FORWARD -d 10.0.0.1/32 -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 10.0.0.1/32 -p tcp -m tcp --dport 443 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 10.0.0.3/32 -p tcp -m tcp --dport 1234 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A interfacce-trusted -i nat -j ACCEPT -A porte-trusted -d 10.0.0.1/32 -p tcp -m tcp --dport 80 -j ACCEPT -A porte-trusted -d 10.0.0.1/32 -p tcp -m tcp --dport 443 -j ACCEPT -A porte-trusted -d 10.0.0.3/32 -p tcp -m tcp --dport 1234 -j ACCEPT COMMIT *nat :PREROUTING ACCEPT [10:600] :INPUT ACCEPT [10:600] :OUTPUT ACCEPT [4:268] :POSTROUTING ACCEPT [18:1108] -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80 -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 443 -j DNAT --to-destination 10.0.0.1:443 -A PREROUTING -d [$EXTIP] -p tcp -m tcp --dport 8069 -j DNAT --to-destination 10.0.0.3:1234 -A POSTROUTING -s 10.0.0.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT -A POSTROUTING -s 10.0.1.0/24 -o nat -j MASQUERADE -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE COMMIT Probably I'm missing something stupid... Thanks in advance for helping :))

    Read the article

  • Packets marked by iptables only sent to the correct routing table sometimes

    - by cookiecaper
    I am trying to route packets generated by a specific user out over a VPN. I have this configuration: $ sudo iptables -S -t nat -P PREROUTING ACCEPT -P OUTPUT ACCEPT -P POSTROUTING ACCEPT -A POSTROUTING -o tun0 -j MASQUERADE $ sudo iptables -S -t mangle -P PREROUTING ACCEPT -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -P POSTROUTING ACCEPT -A OUTPUT -m owner --uid-owner guy -j MARK --set-xmark 0xb/0xffffffff $ sudo ip rule show 0: from all lookup local 32765: from all fwmark 0xb lookup 11 32766: from all lookup main 32767: from all lookup default $ sudo ip route show table 11 10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 10.8.0.6 dev tun0 scope link 10.8.0.1 via 10.8.0.5 dev tun0 0.0.0.0/1 via 10.8.0.5 dev tun0 $ sudo iptables -S -t raw -P PREROUTING ACCEPT -P OUTPUT ACCEPT -A OUTPUT -m owner --uid-owner guy -j TRACE -A OUTPUT -p tcp -m tcp --dport 80 -j TRACE It seems that some sites work fine and use the VPN, but others don't and fall back to the normal interface. This is bad. This is a packet trace that used VPN: Oct 27 00:24:28 agent kernel: [612979.976052] TRACE: raw:OUTPUT:rule:2 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 Oct 27 00:24:28 agent kernel: [612979.976105] TRACE: raw:OUTPUT:policy:3 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 Oct 27 00:24:28 agent kernel: [612979.976164] TRACE: mangle:OUTPUT:rule:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 Oct 27 00:24:28 agent kernel: [612979.976210] TRACE: mangle:OUTPUT:policy:2 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:24:28 agent kernel: [612979.976269] TRACE: nat:OUTPUT:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:24:28 agent kernel: [612979.976320] TRACE: filter:OUTPUT:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:24:28 agent kernel: [612979.976367] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=tun0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:24:28 agent kernel: [612979.976414] TRACE: nat:POSTROUTING:rule:1 IN= OUT=tun0 SRC=XXX.YYY.ZZZ.AAA DST=23.1.17.194 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=14494 DF PROTO=TCP SPT=57502 DPT=80 SEQ=2294732931 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6E01D0000000001030307) UID=999 GID=999 MARK=0xb and this is one that didn't: Oct 27 00:22:41 agent kernel: [612873.662559] TRACE: raw:OUTPUT:rule:2 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 Oct 27 00:22:41 agent kernel: [612873.662609] TRACE: raw:OUTPUT:policy:3 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 Oct 27 00:22:41 agent kernel: [612873.662664] TRACE: mangle:OUTPUT:rule:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 Oct 27 00:22:41 agent kernel: [612873.662709] TRACE: mangle:OUTPUT:policy:2 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:22:41 agent kernel: [612873.662761] TRACE: nat:OUTPUT:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:22:41 agent kernel: [612873.662808] TRACE: filter:OUTPUT:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 MARK=0xb Oct 27 00:22:41 agent kernel: [612873.662855] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=eth0 SRC=XXX.YYY.ZZZ.AAA DST=209.68.27.16 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40425 DF PROTO=TCP SPT=45305 DPT=80 SEQ=604973951 ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A03A6B6960000000001030307) UID=999 GID=999 MARK=0xb I have already tried "ip route flush cache", to no avail. I do not know why the first packet goes through the correct routing table, and the second doesn't. Both are marked. Once again, I do not want ALL packets system-wide to go through the VPN, I only want packets from a specific user (UID=999) to go through the VPN. I am testing ipchicken.com and walmart.com via links, from the same user, same shell. walmart.com appears to use the VPN; ipchicken.com does not. Any help appreciated. Will send 0.5 bitcoins to answerer who makes this fixed.

    Read the article

  • Weird UPD packets on incoming FTP MLSD command

    - by FractalizeR
    Hello. I am developing a firewall script for my server. So far it is working fine, except for FTP. Server is dedicated, CentOS based with static IP. There is no NAT between me and server. IPTables is a firewall. Here is a script I use to configure iptables: http://pastebin.com/f54a70fec I allow all RELATED and ESTABLISHED connections in it and load all conn_track modules. I supposed it to be sufficient in order FTP to work with iptables. The problem is that FTP is not working either in passive or active mode. FileZilla and TotalCommander just hangs on MLSD FTP command. In the server log at the exact moment of FTP connection some weird packets are dropped by firewall: Dec 20 15:37:09 server ntpd[12329]: synchronized to 81.200.8.213, stratum 5 Dec 20 15:37:14 server proftpd[30526]: gsmforum.ru (::ffff:95.24.7.25[::ffff:95.24.7.25]) - FTP session opened. Dec 20 12:37:14 server proftpd[30526]: gsmforum.ru (::ffff:95.24.7.25[::ffff:95.24.7.25]) - Preparing to chroot to directory '/home/gsmforum' Dec 20 15:37:23 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1a:64:6b:1d:67:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=306 TOS=0x00 PREC=0x00 TTL=128 ID=32566 DF PROTO=UDP SPT=68 DPT=67 LEN=286 Dec 20 15:37:25 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1f:29:63:03:de:08:00 SRC=89.111.189.17 DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=13480 PROTO=UDP SPT=1052 DPT=1947 LEN=48 Dec 20 15:37:26 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=61798 PROTO=TCP SPT=4178 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:26 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1a:64:9c:50:e7:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=306 TOS=0x00 PREC=0x00 TTL=128 ID=50015 DF PROTO=UDP SPT=68 DPT=67 LEN=286 Dec 20 15:37:26 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=62305 PROTO=TCP SPT=4178 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:26 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:19:bb:eb:c6:e1:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=30 ID=5245 PROTO=UDP SPT=68 DPT=67 LEN=308 Dec 20 15:37:27 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=63285 PROTO=TCP SPT=4178 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:29 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=391 PROTO=TCP SPT=4183 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:29 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=707 PROTO=TCP SPT=4178 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:30 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=975 PROTO=TCP SPT=4183 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:30 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:15:17:10:c5:9b:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=30 ID=28799 PROTO=UDP SPT=68 DPT=67 LEN=308 Dec 20 15:37:30 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=2020 PROTO=TCP SPT=4187 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:31 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=2383 PROTO=TCP SPT=4183 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:31 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=2533 PROTO=TCP SPT=4187 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=3271 PROTO=TCP SPT=4190 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=77.35.184.49 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=14501 DF PROTO=TCP SPT=1355 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=3700 PROTO=TCP SPT=4187 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=3769 PROTO=TCP SPT=4196 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:32 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=4034 PROTO=TCP SPT=4190 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:33 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=4522 PROTO=TCP SPT=4196 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Dec 20 15:37:33 server kernel: {fw}UNKNOWN:IN=eth0 OUT= MAC=00:15:17:62:db:28:00:1f:26:27:34:c2:08:00 SRC=81.169.231.108 DST=79.174.68.223 LEN=40 TOS=0x00 PREC=0x00 TTL=53 ID=4657 PROTO=TCP SPT=4183 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0 Can you please suggest what is the problem? Everything is working fine except for this damn FTP.

    Read the article

  • tcp handshake failed.client send rst (after syn-ack). can any one advice?

    - by user1495181
    architecture: 2 linux computer connected . on the second (192.168.1.1) one run apache server . I have a small program that take tcp packets from nfqueue change the dst ip to 192.168.1.1 in case that the dst ip is 192.168.1.2 (i know that i can do it with iptables , but my program will do more things in the future), fix check sum and return to the queue. if i call to telnet 192.168.1.1 , means that my program dosnt need to do any manipulation, handshake is OK. If i call to telnet 192.168.1.2 , my program change the dest. server get the syn and return syn-ack, but right after getting the syn-ack the client send rst. Can anyone advice? wireshark of the telnet tcpdump of the telenet above

    Read the article

  • Oracle B2B 11g - Transport Layer Acknowledgement

    - by Nitesh Jain Oracle
    In Health Care Industry,Acknowledgement or Response should be sent back very fast. Once any message received, Acknowledgement should be sent back to TP. Oracle B2B provides a solution to send acknowledgement or Response from transport layer of mllp that is called as immediate acknowledgment. Immediate acknowledgment is generated and transmitted in the transport layer. It is an alternative to the functional acknowledgment, which generates after processing/validating the data in document layer. Oracle B2B provides four types of immediate acknowledgment: Default: Oracle B2B parses the incoming HL7 message and generates an acknowledgment from it. This mode uses the details from incoming payload and generate the acknowledgement based on incoming HL7 message control number, sender and application identification. By default, an Immediate ACK is a generic ACK. Trigger event can also sent back by using Map Trigger Event property. If mapping the MSH.10 of the ACK with the MSH.10 of the incoming business message is required, then enable the Map ACK Control ID property. Simple: B2B sends the predefined acknowledgment message to the sender without parsing the incoming message. Custom: Custom immediate Ack/Response mode gives a user to define their own response/acknowledgement. This is configurable using file in the Custom Immediate ACK File property. Negative: In this case, immediate ACK will be returned only in the case of exceptions.

    Read the article

  • No Telnet login prompt when used over SSH tunnel

    - by SCO
    Hi there ! I have a device, let's call it d1, runnning a lightweight Linux. This device is NATed by my internet box/router, hence not reachable from the Internet. That device runs a telnet daemon on it, and only has root as user (no pwd). Its ip address is 192.168.0.126 on the private network. From the private network (let's say 192.168.0.x), I can do: telnet 192.168.0.126 Where 192.168.0.126 is the IP address in the private network. This works correctly. However, to allow administration, I'd need to access that device from outside of that private network. Hence, I created an SSH tunnel like this on d1 : ssh -R 4455:localhost:23 ussh@s1 s1 is a server somewhere in the private network (but this is for testing purposes only, it will endup somewhere in the Internet), running a standard Linux distro and on which I created a user called 'ussh'. s1 IP address is 192.168.0.48. When I 'telnet' with the following, let's say from c1, 192.168.0.19 : telnet -l root s1 4455 I get : Trying 192.168.0.48... Connected to 192.168.0.48. Escape character is '^]'. Connection closed by foreign host . The connection is closed after roughly 30 seconds, and I didn't log. I tried without the -l switch, without any success. I tried to 'telnet' with IP addresses instead of names to avoid reverse DNS issues (although I added to d1 /etc/hosts a line refering to s1 IP/name, just in case), no success. I tried on another port than 4455, no success. I gathered Wireshark logs from s1. I can see : s1 sends SSH data to c1, c1 ACK s1 performs an AAAA DNS request for c1, gets only the Authoritave nameservers. s1 performs an A DNS request, then gets c1's IP address s1 sends a SYN packet to c1, c1 replies with a RST/ACK s1 sends a SYN to c1, C1 RST/ACK (?) After 0.8 seconds, c1 sends a SYN to s1, s1 SYN/ACK and then c1 ACK s1 sends SSH content to d1, d1 sends an ACK back to s1 s1 retries AAAA and A DNS requests After 5 seconds, s1 retries a SYN to c1, once again it is RST/ACKed by c1. This is repeated 3 more times. The last five packets : d1 sends SSH content to s1, s1 sends ACK and FIN/ACK to c1, c1 replies with FIN/ACK, s1 sends ACK to c1. The connection seems to be closed by the telnet daemon after 22 seconds. AFAIK, there is no way to decode the SSH stream, so I'm really stuck here ... Any ideas ? Thank you !

    Read the article

  • Salesforce/PHP - Bulk Outbound message (SOAP), Time out issue - See update #2

    - by Phill Pafford
    Salesforce can send up to 100 requests inside 1 SOAP message. While sending this type of Bulk Ooutbound message request my PHP script finishes executing but SF fails to accept the ACK used to clear the message queue on the Salesforce side of things. Looking at the Outbound message log (monitoring) I see all the messages in a pending state with the Delivery Failure Reason "java.net.SocketTimeoutException: Read timed out". If my script has finished execution, why do I get this error? I have tried these methods to increase the execution time on my server as I have no access on the Salesforce side: set_time_limit(0); // in the script max_execution_time = 360 ; Maximum execution time of each script, in seconds max_input_time = 360 ; Maximum amount of time each script may spend parsing request data memory_limit = 32M ; Maximum amount of memory a script may consume I used the high settings just for testing. Any thoughts as to why this is failing the ACK delivery back to Salesforce? Here is some of the code: This is how I accept and send the ACK file for the imcoming SOAP request $data = 'php://input'; $content = file_get_contents($data); if($content) { respond('true'); } else { respond('false'); } The respond function function respond($tf) { $ACK = <<<ACK <?xml version = "1.0" encoding = "utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <notifications xmlns="http://soap.sforce.com/2005/09/outbound"> <Ack>$tf</Ack> </notifications> </soapenv:Body> </soapenv:Envelope> ACK; print trim($ACK); } These are in a generic script that I include into the script that uses the data for a specific workflow. I can process about 25 requests (That are in 1 SOAP response) but once I go over that I get the timeout error in the Salesforce queue. for 50 requests is usually takes my PHP script 86.77 seconds. Could it be Apache? PHP? I have also tested just accepting the 100 request SOAP response and just accepting and sending the ACK the queue clears out, so I know it's on my side of things. I show no errors in the apache log, the script runs fine. I did find some info on the Salesforce site but still no luck. Here is the link. Also I'm using the PHP Toolkit 11 (From Salesforce). Other forum with good SF help Thanks for any insight into this, --Phill UPDATE: If I receive the incoming message and print the response, should this happen first regardless if I do anything else after? Or does it wait for my process to finish and then print the response? UPDATE #2: okay I think I have the problem: PHP uses the single thread processing approach and will not send back the ACK file until the thread has completed it's processing. Is there a way to make this a mutli thread process? Thread #1 - accept the incoming SOAP request and send back the ACK Thread #2 - Process the SOAP request I know I could break it up into like a DB table or flat file, but is there a way to accomplish this without doing that? I'm going to try to close the socket after the ACK submission and continue the processing, cross my fingers it will work.

    Read the article

  • FreeBSD slow transfers - RFC 1323 scaling issue?

    - by Trey
    I think I may be having an issue with window scaling (RFC 1323) and am hoping that someone can enlighten me on what's going on. Server: FreeBSD 9, apache22, serving a static 100MB zip file. 192.168.18.30 Client: Mac OS X 10.6, Firefox 192.168.17.47 Network: Only a switch between them - the subnet is 192.168.16/22 (In this test, I also have dummynet filtering simulating an 80ms ping time on all IP traffic. I've seen nearly identical traces with a "real" setup, with real internet traffic/latency also) Questions: Does this look normal? Is packet #2 specifying a window size of 65535 and a scale of 512? Is packet #5 then shrinking the window size so it can use the 512 scale and still keep the overall calculated window size near 64K? Why is the window scale so high? Here are the first 6 packets from wireshark. For packets 5 and 6 I've included the details showing the window size and scaling factor being used for the data transfer. Code: No. Time Source Destination Protocol Length Info 108 6.699922 192.168.17.47 192.168.18.30 TCP 78 49190 http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=8 TSval=945617489 TSecr=0 SACK_PERM=1 115 6.781971 192.168.18.30 192.168.17.47 TCP 74 http 49190 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=512 SACK_PERM=1 TSval=2617517338 TSecr=945617489 116 6.782218 192.168.17.47 192.168.18.30 TCP 66 49190 http [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSval=945617490 TSecr=2617517338 117 6.782220 192.168.17.47 192.168.18.30 HTTP 490 GET /utils/speedtest/large.file.zip HTTP/1.1 118 6.867070 192.168.18.30 192.168.17.47 TCP 375 [TCP segment of a reassembled PDU] Details: Transmission Control Protocol, Src Port: http (80), Dst Port: 49190 (49190), Seq: 1, Ack: 425, Len: 309 Source port: http (80) Destination port: 49190 (49190) [Stream index: 4] Sequence number: 1 (relative sequence number) [Next sequence number: 310 (relative sequence number)] Acknowledgement number: 425 (relative ack number) Header length: 32 bytes Flags: 0x018 (PSH, ACK) Window size value: 130 [Calculated window size: 66560] [Window size scaling factor: 512] Checksum: 0xd182 [validation disabled] Options: (12 bytes) No-Operation (NOP) No-Operation (NOP) Timestamps: TSval 2617517423, TSecr 945617490 [SEQ/ACK analysis] TCP segment data (309 bytes) Note: originally posted http://forums.freebsd.org/showthread.php?t=32552

    Read the article

  • Concurrent Threads in C# using BackgroundWorker

    - by Jim Fell
    My C# application is such that a background worker is being used to wait for the acknowledgement of some transmitted data. Here is some psuedo code demonstrating what I'm trying to do: UI_thread { TransmitData() { // load data for tx // fire off TX background worker } RxSerialData() { // if received data is ack, set ack received flag } } TX_thread { // transmit data // set ack wait timeout // fire off ACK background worker // wait for ACK background worker to complete // evaluate status of ACK background worker as completed, failed, etc. } ACK_thread { // wait for ack received flag to be set } What happens is that the ACK BackgroundWorker times out, and the acknowledgement is never received. I'm fairly certain that it is being transmitted by the remote device because that device has not changed at all, and the C# application is transmitting. I have changed the ack thread from this (when it was working)... for( i = 0; (i < waitTimeoutVar) && (!bAckRxd); i++ ) { System.Threading.Thread.Sleep(1); } ...to this... DateTime dtThen = DateTime.Now(); DateTime dtNow; TimeSpan stTime; do { dtNow = DateTime.Now(); stTime = dtNow - dtThen; } while ( (stTime.TotalMilliseconds < waitTimeoutVar) && (!bAckRxd) ); The latter generates a very acurate wait time, as compared to the former. However, I am wondering if removal of the Sleep function is interferring with the ability to receive serial data. Does C# only allow one thread to run at a time, that is, do I have to put threads to sleep at some time to allow other threads to run? Any thoughts or suggestions you may have would be appreciated. I am using Microsoft Visual C# 2008 Express Edition. Thanks.

    Read the article

  • Building a webserver, client doesn't acknowledge HTTP 200 OK frame.

    - by Evert
    Hi there, I'm building my own webserver based on a tutorial. I have found a simple way to initiate a TCP connection and send one segment of http data (the webserver will run on a microcontroller, so it will be very small) Anyway, the following is the sequence I need to go through: receive SYN send SYN,ACK receive ACK (the connection is now established) receive ACK with HTTP GET command send ACK send FIN,ACK with HTTP data (e.g 200 OK) receive FIN,ACK <- I don't recieve this packet! send ACK Everything works fine until I send my acknowledgement and HTTP 200 OK message. The client won't send an acknowledgement to those two packages and thus no webpage is being displayed. I've added a pcap file of the sequence how I recorded it with wireshark. Pcap file: http://cl.ly/5f5 (now it's the right data) All sequence and acknowledgement numbers are correct, checksum are ok. Flags are also right. I have no idea what is going wrong.

    Read the article

  • Why would one server be sending DUP ACK packets to one PC, which is responding with HTTP RST packets?

    - by IronicMuffin
    I'm not a network profressional, so please excuse any wrong language. I was debugging why my DNS traffic was a constant 160Kbps on our corporate network. I opened up a wireshark trace, and I see one PC of a coworker broadcasting HTTP [RST] packets to one of our DMZ servers at the rate of 1000 a second. He restarted his machine, and as soon as it went offline, the server started broadcasting [DUP] [ACK] packets, until he came back online. It then resumed the HTTP [RST] packets. Apparently this server has been doing this kind of behavior since it went live. I believe it did this with a printer and an access point as well. Can anyone explain why this behavior is occurring? Any solutions? The initial research was done because there have been "bandwidth issues" and I wonder if this is contributing.

    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

  • Java CORBA Client Disconnects Immediately

    - by Benny
    I have built a Java CORBA application that subscribes to an event server. The application narrows and logs on just fine, but as soon as an event is sent to the client, it breaks with the error below. Please advise. 2010/04/25!13.00.00!E00555!enserver!EventServiceIF_i.cpp!655!PID(7390)!enserver - e._info=system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0' TAO exception, minor code = 54410093 (invocation connect failed; ECONNRESET), completed = NO EDIT: Please note, this only happens when running on some machines. It works on some, but not others. Even on the same platform (I've tried Windows XP/7 and CentOS linux) Some work, some don't... Here is the WireShark output...looks like the working PC is much more interactive with the network compared to the non-working PC. Working PC No. Time Source Destination Protocol Info 62 28.837255 10.10.10.209 10.10.10.250 TCP 50169 > 23120 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=8 63 28.907068 fe80::5de0:8d21:937e:c649 ff02::1:3 LLMNR Standard query A isatap 64 28.907166 10.10.10.209 224.0.0.252 LLMNR Standard query A isatap 65 29.107259 10.10.10.209 10.255.255.255 NBNS Name query NB ISATAP<00> 66 29.227000 10.10.10.250 10.10.10.209 TCP 23120 > 50169 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1260 WS=0 67 29.227032 10.10.10.209 10.10.10.250 TCP 50169 > 23120 [ACK] Seq=1 Ack=1 Win=66560 Len=0 68 29.238063 10.10.10.209 10.10.10.250 GIOP GIOP 1.1 Request s=326 id=5 (two-way): op=logon 69 29.291765 10.10.10.250 10.10.10.209 GIOP GIOP 1.1 Reply s=420 id=5: No Exception 70 29.301395 10.10.10.209 10.10.10.250 GIOP GIOP 1.1 Request s=369 id=6 (two-way): op=registerEventStat 71 29.348275 10.10.10.250 10.10.10.209 GIOP GIOP 1.1 Reply s=60 id=6: No Exception 72 29.405250 10.10.10.209 10.10.10.250 TCP 50170 > telnet [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=8 73 29.446055 10.10.10.250 10.10.10.209 TCP telnet > 50170 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1260 WS=0 74 29.446128 10.10.10.209 10.10.10.250 TCP 50170 > telnet [ACK] Seq=1 Ack=1 Win=66560 Len=0 75 29.452021 10.10.10.209 10.10.10.250 TELNET Telnet Data ... 76 29.483537 10.10.10.250 10.10.10.209 TELNET Telnet Data ... 77 29.483651 10.10.10.209 10.10.10.250 TELNET Telnet Data ... 78 29.523463 10.10.10.250 10.10.10.209 TCP telnet > 50170 [ACK] Seq=4 Ack=5 Win=32768 Len=0 79 29.554954 10.10.10.209 10.10.10.250 TCP 50169 > 23120 [ACK] Seq=720 Ack=505 Win=66048 Len=0 Non-working PC No. Time Source Destination Protocol Info 1 0.000000 10.10.10.209 10.10.10.250 TCP 64161 > 23120 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=8 2 2.999847 10.10.10.209 10.10.10.250 TCP 64161 > 23120 [SYN] Seq=0 Win=8192 Len=0 MSS=1260 WS=8 3 4.540773 Cisco_3c:78:00 Cisco-Li_55:87:72 ARP Who has 10.0.0.1? Tell 10.10.10.209 4 4.540843 Cisco-Li_55:87:72 Cisco_3c:78:00 ARP 10.0.0.1 is at 00:1a:70:55:87:72 5 8.992284 10.10.10.209 10.10.10.250 TCP 64161 > 23120 [SYN] Seq=0 Win=8192 Len=0 MSS=1260

    Read the article

  • Salesforce/PHP - Bulk Outbound message (SOAP), Time out issue

    - by Phill Pafford
    Salesforce can send up to 100 requests inside 1 SOAP message. While sending this type of Bulk Ooutbound message request my PHP script finishes executing but SF fails to accept the ACK used to clear the message queue on the Salesforce side of things. Looking at the Outbound message log (monitoring) I see all the messages in a pending state with the Delivery Failure Reason "java.net.SocketTimeoutException: Read timed out". If my script has finished execution, why do I get this error? I have tried these methods to increase the execution time on my server as I have no access on the Salesforce side: set_time_limit(0); // in the script max_execution_time = 360 ; Maximum execution time of each script, in seconds max_input_time = 360 ; Maximum amount of time each script may spend parsing request data memory_limit = 32M ; Maximum amount of memory a script may consume I used the high settings just for testing. Any thoughts as to why this is failing the ACK delivery back to Salesforce? Here is some of the code: This is how I accept and send the ACK file for the imcoming SOAP request $data = 'php://input'; $content = file_get_contents($data); if($content) { respond('true'); } else { respond('false'); } The respond function function respond($tf) { $ACK = <<<ACK <?xml version = "1.0" encoding = "utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <notifications xmlns="http://soap.sforce.com/2005/09/outbound"> <Ack>$tf</Ack> </notifications> </soapenv:Body> </soapenv:Envelope> ACK; print trim($ACK); } These are in a generic script that I include into the script that uses the data for a specific workflow. I can process about 25 requests (That are in 1 SOAP response) but once I go over that I get the timeout error in the Salesforce queue. for 50 requests is usually takes my PHP script 86.77 seconds. Could it be Apache? PHP? I have also tested just accepting the 100 request SOAP response and just accepting and sending the ACK the queue clears out, so I know it's on my side of things. I show no errors in the apache log, the script runs fine. Thanks for any insight into this, --Phill

    Read the article

  • recvfrom() return values in Stop-and-Wait UDP?

    - by mavErick
    I am trying to implement a Stop-and-Wait UDP client-server socket program in C. As known, there are basically three possible scenarios for Stop-and-Wait flow control. i.e., After transmitting a packet, the sender receives a correct ACK and thus starts transmitting the next packet; the sender receives an incorrect ACK and thus retransmits this packet; the sender receives no ACK within a TIMEOUT and thus retransmits this packet. My idea is to differentiate these three scenarios with the return value of recvfrom() on the sender side. For scenario 1&2: recvfrom() just returns the length of the received ACK. Since in my implementation the incorrect ACK is of the same length of the correct one, so I will have to go deeper and check the contents of the ACK. It's not a big deal. I know how to do. Problems come when I am trying to recognize scenario 3 where no ACK is received. What confuses me is that my recvfrom() is within a while loop, so the recvfrom() will be called constantly. What will it return when the receiver is not actually sending the sender ACK? Is it 0 or 1?

    Read the article

  • Java, server client TCP communication ends with RST

    - by Senne
    I'm trying to figure out if this is normal. Because without errors, a connection should be terminated by: FIN -> <- ACK <- FIN ACK -> I get this at the end of a TCP connection (over SSL, but i also get it with non-encrypted): From To 1494 server client TCP search-agent > 59185 [PSH, ACK] Seq=25974 Ack=49460 Win=63784 Len=50 1495 client server TCP 59185 > search-agent [ACK] Seq=49460 Ack=26024 Win=63565 Len=0 1496 client server TCP 59185 > search-agent [PSH, ACK] Seq=49460 Ack=26024 Win=63565 Len=23 1497 client server TCP 59185 > search-agent [FIN, ACK] Seq=49483 Ack=26024 Win=63565 Len=0 1498 server client TCP search-agent > 59185 [PSH, ACK] Seq=26024 Ack=49484 Win=63784 Len=23 1499 client server TCP 59185 > search-agent [RST, ACK] Seq=49484 Ack=26047 Win=0 Len=0 The client exits normally and reaches socket.close, shouldn't then the connection be shut down normally, without a reset? I can't find anything about the TCP streams of java on google... Here is my code: Server: package Security; import java.io.*; import java.net.*; import javax.net.ServerSocketFactory; import javax.net.ssl.*; import java.util.*; public class SSLDemoServer { private static ServerSocket serverSocket; private static final int PORT = 1234; public static void main(String[] args) throws IOException { int received = 0; String returned; ObjectInputStream input = null; PrintWriter output = null; Socket client; System.setProperty("javax.net.ssl.keyStore", "key.keystore"); System.setProperty("javax.net.ssl.keyStorePassword", "vwpolo"); System.setProperty("javax.net.ssl.trustStore", "key.keystore"); System.setProperty("javax.net.ssl.trustStorePassword", "vwpolo"); try { System.out.println("Trying to set up server ..."); ServerSocketFactory factory = SSLServerSocketFactory.getDefault(); serverSocket = factory.createServerSocket(PORT); System.out.println("Server started!\n"); } catch (IOException ioEx) { System.out.println("Unable to set up port!"); ioEx.printStackTrace(); System.exit(1); } while(true) { client = serverSocket.accept(); System.out.println("Client trying to connect..."); try { System.out.println("Trying to create inputstream..."); input = new ObjectInputStream(client.getInputStream()); System.out.println("Trying to create outputstream..."); output = new PrintWriter(client.getOutputStream(), true); System.out.println("Client successfully connected!"); while( true ) { received = input.readInt(); returned = Integer.toHexString(received); System.out.print(" " + received); output.println(returned.toUpperCase()); } } catch(SSLException sslEx) { System.out.println("Connection failed! (non-SSL connection?)\n"); client.close(); continue; } catch(EOFException eofEx) { System.out.println("\nEnd of client data.\n"); } catch(IOException ioEx) { System.out.println("I/O problem! (correct inputstream?)"); } try { input.close(); output.close(); } catch (Exception e) { } client.close(); System.out.println("Client closed.\n"); } } } Client: package Security; import java.io.*; import java.net.*; import javax.net.ssl.*; import java.util.*; public class SSLDemoClient { private static InetAddress host; private static final int PORT = 1234; public static void main(String[] args) { System.setProperty("javax.net.ssl.keyStore", "key.keystore"); System.setProperty("javax.net.ssl.keyStorePassword", "vwpolo"); System.setProperty("javax.net.ssl.trustStore", "key.keystore"); System.setProperty("javax.net.ssl.trustStorePassword", "vwpolo"); System.out.println("\nCreating SSL socket ..."); SSLSocket socket = null; try { host = InetAddress.getByName("192.168.56.101"); SSLSocketFactory factory = (SSLSocketFactory) SSLSocketFactory.getDefault(); socket = (SSLSocket) factory.createSocket(host, PORT); socket.startHandshake(); } catch(UnknownHostException uhEx) { System.out.println("\nHost ID not found!\n"); System.exit(1); } catch(SSLException sslEx) { System.out.println("\nHandshaking unsuccessful ..."); System.exit(1); } catch (IOException e) { e.printStackTrace(); } System.out.println("\nHandshaking succeeded ...\n"); SSLClientThread client = new SSLClientThread(socket); SSLReceiverThread receiver = new SSLReceiverThread(socket); client.start(); receiver.start(); try { client.join(); receiver.join(); System.out.println("Trying to close..."); socket.close(); } catch(InterruptedException iEx) { iEx.printStackTrace(); } catch(IOException ioEx) { ioEx.printStackTrace(); } System.out.println("\nClient finished."); } } class SSLClientThread extends Thread { private SSLSocket socket; public SSLClientThread(SSLSocket s) { socket = s; } public void run() { try { ObjectOutputStream output = new ObjectOutputStream(socket.getOutputStream()); for( int i = 1; i < 1025; i++) { output.writeInt(i); sleep(10); output.flush(); } output.flush(); sleep(1000); output.close(); } catch(IOException ioEx) { System.out.println("Socket closed or unable to open socket."); } catch(InterruptedException iEx) { iEx.printStackTrace(); } } } class SSLReceiverThread extends Thread { private SSLSocket socket; public SSLReceiverThread(SSLSocket s) { socket = s; } public void run() { String response = null; BufferedReader input = null; try { input = new BufferedReader( new InputStreamReader(socket.getInputStream())); try { response = input.readLine(); while(!response.equals(null)) { System.out.print(response + " "); response = input.readLine(); } } catch(Exception e) { System.out.println("\nEnd of server data.\n"); } input.close(); } catch(IOException ioEx) { ioEx.printStackTrace(); } } }

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >