what is the error message? could you check for me?

Question

Hi,

Please check for me below link:

is it block the 443? but i can telnet with 443.

what is the root cause of this issue?

http://www.sendspace.com/file/qyv69e

Please help me, thanks.

ko htwe

Answer 1

0

The screen shot doesn't tell much except there is a reset coming back as an answer to a SYN, so it looks like the session is refused. You'd need to provide more detailed information to see what's going on.

BTW: removing parts of the target IP address in the packet list in the screenshot (where you put "x.x.x") doesn't help much hiding it when you forget that it is also seen in the IP layer in the decode pane...

answered 19 Apr '13, 00:04

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

edited 19 Apr '13, 00:05

Thanks Jasper,

you can see below full of the list

http://www.sendspace.com/file/8w0rta

i want to check 203.126.29.157/57 to 192.168.100.148 , any port number is block?

Thanks,

Ko Htwe

(19 Apr '13, 00:14) aungkohtwe

No, there is no general port number block, because there are conversations in the trace you provided where data is exchanged successfully. Maybe there is a connection rate limit (meaning: if you try to connect too often, you'll be refused) since there are a few session rejects, but the port seems to be open generally.

(19 Apr '13, 00:26) Jasper ♦♦

Thanks Jasper,

please help me check again for me, I am still leaner for wireshark

http://www.sendspace.com/file/5pcgng

picture 1_2 is ACK and RST and Win = 0 Len = 0, what is that mean?

picture 2_2 is TCP fast retransmission, is the packet lost?

Sometime Win number is bigger than ACK. why ? is it bcs of Duplicate packets?

Best Regards and Thanks,

Ko Htwe

(19 Apr '13, 00:37) aungkohtwe

[I converted your answer to a comment again; please use comments for follow ups]

Okay, so the reset in packet #63 seems pretty normal; you have a conversation starting in packet 36 which exchanges some data and gets torn down (even if a bit harsh, FIN followed by RST, but not unheard of). Filter used: "(ip.addr eq 203.126.29.157 and ip.addr eq 192.168.100.148) and (tcp.port eq 5061 and tcp.port eq 57810)"

The other one (RST in 685) seems more problematic: it is torn down as a result of no packets coming back from 203.126.29.158 for almost 15 seconds. On a closer look it is not that bad - the client acknowledges incoming data in 141 and has nothing else to say, so the connection is terminated after an inactivity timeout. Pretty normal, too. Filter used: "(ip.addr eq 192.168.100.148 and ip.addr eq 203.126.29.158) and (tcp.port eq 57811 and tcp.port eq 443)"

So far, nothing bad is happening with the resets in your trace ;-)

(19 Apr '13, 00:51) Jasper ♦♦

Answer 2

UPDATE

is it block the 443? but i can telnet with 443.

I just saw the pcap file you posted. The PCAP file contains a secure SIP session (port 5061), not a HTTPS connection (port 443) to the server in question (203.126.29.157). Maybe that's your problem, a misunderstanding of the ports being used!?! As I said, the server also accepts TCP connections on port 443, but it does not respond to the SSL handshake. That could be an error or it could be intentional. Please ask the operator of the site.

is it block the 443? but i can telnet with 443.

no, port 443 is not blocked.

what is the root cause of this issue?

The server accepts the TCP connection, but it does not answer the SSL/TLS handshake. It also does not answer a HTTP request on port 443, which is a common config error of web servers.

So, it could be a general configuration error or a problem with the server software. Please contact the owner of the site and ask for help.

curl

C:\tools\curl>curl -v https://203.126.29.157
 About to connect() to 203.126.29.157 port 443 (#0)
   Trying 203.126.29.157...
 connected
 Connected to 203.126.29.157 (203.126.29.157) port 443 (#0)
 SSLv3, TLS handshake, Client hello (1):
 Unknown SSL protocol error in connection to 203.126.29.157:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to 203.126.29.157:443

openssl

C:\tools\openssl\bin>openssl s_client -connect 203.126.29.157:443 -debug
Loading 'screen' into random state - done
CONNECTED(00000780)
write to 0xa72210 [0xa72cc8] (210 bytes => 210 (0xD2))
0000 - 16 03 01 00 cd 01 00 00-c9 03 01 51 70 fa a2 c1   ...........Qp...
0010 - 58 7f f8 5f e0 cd 1e 16-8b 03 83 e5 40 0f c9 bc   [email protected]
0020 - d7 ad 39 c2 96 55 c1 e6-a3 b7 88 00 00 5c c0 14   ..9..U.......\..
0030 - c0 0a 00 39 00 38 00 88-00 87 c0 0f c0 05 00 35   ...9.8.........5
0040 - 00 84 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a   ................
0050 - c0 13 c0 09 00 33 00 32-00 9a 00 99 00 45 00 44   .....3.2.....E.D
0060 - c0 0e c0 04 00 2f 00 96-00 41 00 07 c0 11 c0 07   ...../...A......
0070 - c0 0c c0 02 00 05 00 04-00 15 00 12 00 09 00 14   ................
0080 - 00 11 00 08 00 06 00 03-00 ff 01 00 00 44 00 0b   .............D..
0090 - 00 04 03 00 01 02 00 0a-00 34 00 32 00 01 00 02   .........4.2....
00a0 - 00 03 00 04 00 05 00 06-00 07 00 08 00 09 00 0a   ................
00b0 - 00 0b 00 0c 00 0d 00 0e-00 0f 00 10 00 11 00 12   ................
00c0 - 00 13 00 14 00 15 00 16-00 17 00 18 00 19 00 23   ...............#
00d2 - <spaces nuls="">
read from 0xa72210 [0xa78228] (7 bytes => -1 (0xFFFFFFFF))
write:errno=10054
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 210 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

cloudshark

https://www.cloudshark.org/captures/a3e0573bbce3

Regards
Kurt