• Re: TCP connection stalls during SSL handshake

    From opendog1@gmail.com@1:0/0 to All on Mon Jun 24 19:16:54 2013

    It's a bit late ... but what was the reason for the retransmissions? I have similar problems here.

    Danke,
    Bela

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From anoopk6@gmail.com@1:0/0 to All on Tue Oct 1 07:49:06 2013
    I also ran in to same issue while performing LDAP SSL operation from Java c= ode. Any idea what is the root cause of=20
    this problem. Are there any workarounds ?

    On Tuesday, 12 April 2011 21:12:16 UTC+5:30, Tino Schwarze wrote:
    Hi there,
    =20
    I'm currently chasing a rather weird problem. We've got a Java based
    program to connect to a Webshop (for importing/exporting data). Of
    course, we use SSL. (Webshop is on a webspace, client is behind DSL.)
    =20
    It used to work(tm) but somehow stopped working - the program could not access the Webshop anymore. Accessing by browser (from same machine)
    works.
    =20
    It's getting stranger... there's a proxy inbetween which is used by the
    Java app. I'm ssh-ing to the proxy machine (an OpenSUSE box, running
    kernel 2.6.27.56), I use lynx - it works. I use wget - it works.
    =20
    For testing, I made a very simple program which basically does
    =20
    new URL("https://my-url/").openConnection();
    =20
    and copies everything to stdout. Now the request just gets stuck.
    =20
    So I take a traffic dump, load it into Wireshark and see (sorry for the
    long lines):
    =20
    No. Time Source Destination Protocol =
    Size Info
    1 0.000000 212.80.cli.ent 188.40.t.srv TCP =
    74 49047 > https [SYN] Seq=3D0 Win=3D5840 Len=3D0 MSS=3D1460 SACK_PERM=
    =3D1 TSV=3D4228721087 TSER=3D0 WS=3D5
    2 0.031476 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D5840 Len=3D0 MSS=3D146=
    0 SACK_PERM=3D1 WS=3D6
    3 0.031527 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D1 Ack=3D1 Win=3D5856 Len=3D0
    4 0.219837 212.80.cli.ent 188.40.t.srv SSLv2 =
    166 Client Hello
    5 0.251510 188.40.t.srv 212.80.cli.ent TCP =
    60 https > 49047 [ACK] Seq=3D1 Ack=3D113 Win=3D5888 Len=3D0
    6 0.260881 188.40.t.srv 212.80.cli.ent TLSv1 =
    1514 Server Hello
    7 0.260919 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D1461 Win=3D8768 Len=3D0
    8 0.267468 188.40.t.srv 212.80.cli.ent TCP =
    1514 [TCP segment of a reassembled PDU]
    9 0.267506 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D2921 Win=3D11680 Len=3D0
    10 0.295676 188.40.t.srv 212.80.cli.ent TLSv1 =
    604 Certificate, Server Hello Done
    11 0.295715 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D3471 Win=3D14624 Len=3D0
    12 0.313933 212.80.cli.ent 188.40.t.srv TLSv1 =
    321 Client Key Exchange
    13 0.318689 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 Change Cipher Spec
    14 0.321350 212.80.cli.ent 188.40.t.srv TLSv1 =
    91 Encrypted Handshake Message
    15 0.353167 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D6912 Len=3D0 SLE=3D386=
    SRE=3D423
    16 0.582048 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    17 1.046053 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    18 1.974052 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    19 3.830055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    20 7.542049 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    21 14.966051 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    22 29.814055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    23 59.510067 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    24 70.992437 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [FIN, ACK] Seq=3D423 Ack=3D3471 Win=3D14624 Len=3D0
    25 71.023543 188.40.t.srv 212.80.cli.ent TCP =
    66 [TCP Dup ACK 15#1] https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D691=
    2 Len=3D0 SLE=3D386 SRE=3D424
    =20
    The FIN,ACK gets sent when I press CTRL-C to abort the program.
    =20
    I captured all traffic going to the server (tcpdump ... host 188.40.t.srv=
    ).
    It looks like the TCP session gets stuck at packet 13. I don't know
    where to look next or whom to ask.
    =20
    I checked that the following things work:
    - access $url via Browser, lynx and wget
    - access $url via said Java program via several other internet
    connections (other DSL providers, from other servers located at a
    certain hoster)
    =20
    After all, I can rule out:
    - fundamental Java/Server/SSL issue (because Java program works with
    same Java version on other system)
    - fundamental network issue (because other browsers work)
    =20
    Funny thing is, it worked once today - even though I didn't change
    anything.
    =20
    Any hints?
    =20
    Thanks,
    =20
    Tino.
    =20
    PS: I found someone with a very similar problem: http://seclists.org/wireshark/2010/Jun/85 but no anwer nor solution (and
    he's getting Dup ACKs at least while I'm only seeing a DUP ACK after connection is closed.)
    =20
    --=20
    "What we nourish flourishes." - "Was wir n=E4hren erbl=FCht."
    =20
    www.tisc.de

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Jamma Tino Schwarze@110:110/2002 to All on Tue Oct 1 14:02:53 2013
    Hi,

    you might suffer from entropy pool depletion. Quick check:
    # cat /proc/sys/kernel/random/entropy_avail
    should display something above 1000 and not go down below 200 during
    normal operation. It worked once because the entropy pool gathered
    enough entropy (e.g. from network activity or whatnot) to provide
    sufficient randomness.

    We've had connections to Oracle DB get stuck during handshake because of
    this issue. Google for haveged for a solution.

    HTH,

    Jamma.

    anoopk6@gmail.com wrote:
    I also ran in to same issue while performing LDAP SSL operation from Java
    code. Any idea what is the root cause of
    this problem. Are there any workarounds ?

    On Tuesday, 12 April 2011 21:12:16 UTC+5:30, Tino Schwarze wrote:
    Hi there,

    I'm currently chasing a rather weird problem. We've got a Java based
    program to connect to a Webshop (for importing/exporting data). Of
    course, we use SSL. (Webshop is on a webspace, client is behind DSL.)

    It used to work(tm) but somehow stopped working - the program could not
    access the Webshop anymore. Accessing by browser (from same machine)
    works.

    It's getting stranger... there's a proxy inbetween which is used by the
    Java app. I'm ssh-ing to the proxy machine (an OpenSUSE box, running
    kernel 2.6.27.56), I use lynx - it works. I use wget - it works.

    For testing, I made a very simple program which basically does

    new URL("https://my-url/").openConnection();

    and copies everything to stdout. Now the request just gets stuck.

    So I take a traffic dump, load it into Wireshark and see (sorry for the
    long lines):

    No. Time Source Destination Protocol Size Info
    1 0.000000 212.80.cli.ent 188.40.t.srv TCP 74
    49047 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=4228721087 TSER=0 WS=5
    2 0.031476 188.40.t.srv 212.80.cli.ent TCP 66
    https > 49047 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=6
    3 0.031527 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [ACK] Seq=1 Ack=1 Win=5856 Len=0
    4 0.219837 212.80.cli.ent 188.40.t.srv SSLv2 166 Client Hello
    5 0.251510 188.40.t.srv 212.80.cli.ent TCP 60
    https > 49047 [ACK] Seq=1 Ack=113 Win=5888 Len=0
    6 0.260881 188.40.t.srv 212.80.cli.ent TLSv1 1514 Server Hello
    7 0.260919 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [ACK] Seq=113 Ack=1461 Win=8768 Len=0
    8 0.267468 188.40.t.srv 212.80.cli.ent TCP 1514 [TCP segment of a reassembled PDU]
    9 0.267506 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [ACK] Seq=113 Ack=2921 Win=11680 Len=0
    10 0.295676 188.40.t.srv 212.80.cli.ent TLSv1 604 Certificate, Server Hello Done
    11 0.295715 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [ACK] Seq=113 Ack=3471 Win=14624 Len=0
    12 0.313933 212.80.cli.ent 188.40.t.srv TLSv1 321 Client Key Exchange
    13 0.318689 212.80.cli.ent 188.40.t.srv TLSv1 60
    Change Cipher Spec
    14 0.321350 212.80.cli.ent 188.40.t.srv TLSv1 91
    Encrypted Handshake Message
    15 0.353167 188.40.t.srv 212.80.cli.ent TCP 66
    https > 49047 [ACK] Seq=3471 Ack=380 Win=6912 Len=0 SLE=386 SRE=423
    16 0.582048 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    17 1.046053 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    18 1.974052 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    19 3.830055 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    20 7.542049 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    21 14.966051 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    22 29.814055 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    23 59.510067 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    24 70.992437 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [FIN, ACK] Seq=423 Ack=3471 Win=14624 Len=0
    25 71.023543 188.40.t.srv 212.80.cli.ent TCP 66
    [TCP Dup ACK 15#1] https > 49047 [ACK] Seq=3471 Ack=380 Win=6912 Len=0 SLE=386 SRE=424

    The FIN,ACK gets sent when I press CTRL-C to abort the program.

    I captured all traffic going to the server (tcpdump ... host 188.40.t.srv). >> It looks like the TCP session gets stuck at packet 13. I don't know
    where to look next or whom to ask.

    I checked that the following things work:
    - access $url via Browser, lynx and wget
    - access $url via said Java program via several other internet
    connections (other DSL providers, from other servers located at a
    certain hoster)

    After all, I can rule out:
    - fundamental Java/Server/SSL issue (because Java program works with
    same Java version on other system)
    - fundamental network issue (because other browsers work)

    Funny thing is, it worked once today - even though I didn't change
    anything.

    Any hints?

    Thanks,

    Tino.

    PS: I found someone with a very similar problem:
    http://seclists.org/wireshark/2010/Jun/85 but no anwer nor solution (and
    he's getting Dup ACKs at least while I'm only seeing a DUP ACK after
    connection is closed.)

    --
    "What we nourish flourishes." - "Was wir n„hren erblht."

    www.tisc.de

    --
    "What we nourish flourishes." - "Was wir n„hren erblht."

    www.tisc.de

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Individual Network Chemnitz, FRG (110:110/2002@linuxnet)
  • From anoopk6@gmail.com@1:0/0 to All on Wed Oct 2 09:22:54 2013
    Thanks . I will investigate the entropy parameter.

    Packet capture indicates that the following happens for more than 5 min=20

    client ------ Client Key Exchange ----------------------> Server
    client ------ Client Key Exchange(Re-transmission)------> Server
    client <----- ACK -------------------------------------- Server =20
    client ------ Client Key Exchange(Re-transmission)------> Server=20
    client <------ Dup ACK --------------------------------- Server
    client ------ Client Key Exchange(Re-transmission)------> Server=20
    client <------ Dup ACK --------------------------------- Server

    Anoop


    On Tuesday, 12 April 2011 21:12:16 UTC+5:30, Tino Schwarze wrote:
    Hi there,
    =20
    I'm currently chasing a rather weird problem. We've got a Java based
    program to connect to a Webshop (for importing/exporting data). Of
    course, we use SSL. (Webshop is on a webspace, client is behind DSL.)
    =20
    It used to work(tm) but somehow stopped working - the program could not access the Webshop anymore. Accessing by browser (from same machine)
    works.
    =20
    It's getting stranger... there's a proxy inbetween which is used by the
    Java app. I'm ssh-ing to the proxy machine (an OpenSUSE box, running
    kernel 2.6.27.56), I use lynx - it works. I use wget - it works.
    =20
    For testing, I made a very simple program which basically does
    =20
    new URL("https://my-url/").openConnection();
    =20
    and copies everything to stdout. Now the request just gets stuck.
    =20
    So I take a traffic dump, load it into Wireshark and see (sorry for the
    long lines):
    =20
    No. Time Source Destination Protocol =
    Size Info
    1 0.000000 212.80.cli.ent 188.40.t.srv TCP =
    74 49047 > https [SYN] Seq=3D0 Win=3D5840 Len=3D0 MSS=3D1460 SACK_PERM=
    =3D1 TSV=3D4228721087 TSER=3D0 WS=3D5
    2 0.031476 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D5840 Len=3D0 MSS=3D146=
    0 SACK_PERM=3D1 WS=3D6
    3 0.031527 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D1 Ack=3D1 Win=3D5856 Len=3D0
    4 0.219837 212.80.cli.ent 188.40.t.srv SSLv2 =
    166 Client Hello
    5 0.251510 188.40.t.srv 212.80.cli.ent TCP =
    60 https > 49047 [ACK] Seq=3D1 Ack=3D113 Win=3D5888 Len=3D0
    6 0.260881 188.40.t.srv 212.80.cli.ent TLSv1 =
    1514 Server Hello
    7 0.260919 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D1461 Win=3D8768 Len=3D0
    8 0.267468 188.40.t.srv 212.80.cli.ent TCP =
    1514 [TCP segment of a reassembled PDU]
    9 0.267506 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D2921 Win=3D11680 Len=3D0
    10 0.295676 188.40.t.srv 212.80.cli.ent TLSv1 =
    604 Certificate, Server Hello Done
    11 0.295715 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D3471 Win=3D14624 Len=3D0
    12 0.313933 212.80.cli.ent 188.40.t.srv TLSv1 =
    321 Client Key Exchange
    13 0.318689 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 Change Cipher Spec
    14 0.321350 212.80.cli.ent 188.40.t.srv TLSv1 =
    91 Encrypted Handshake Message
    15 0.353167 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D6912 Len=3D0 SLE=3D386=
    SRE=3D423
    16 0.582048 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    17 1.046053 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    18 1.974052 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    19 3.830055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    20 7.542049 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    21 14.966051 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    22 29.814055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    23 59.510067 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    24 70.992437 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [FIN, ACK] Seq=3D423 Ack=3D3471 Win=3D14624 Len=3D0
    25 71.023543 188.40.t.srv 212.80.cli.ent TCP =
    66 [TCP Dup ACK 15#1] https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D691=
    2 Len=3D0 SLE=3D386 SRE=3D424
    =20
    The FIN,ACK gets sent when I press CTRL-C to abort the program.
    =20
    I captured all traffic going to the server (tcpdump ... host 188.40.t.srv=
    ).
    It looks like the TCP session gets stuck at packet 13. I don't know
    where to look next or whom to ask.
    =20
    I checked that the following things work:
    - access $url via Browser, lynx and wget
    - access $url via said Java program via several other internet
    connections (other DSL providers, from other servers located at a
    certain hoster)
    =20
    After all, I can rule out:
    - fundamental Java/Server/SSL issue (because Java program works with
    same Java version on other system)
    - fundamental network issue (because other browsers work)
    =20
    Funny thing is, it worked once today - even though I didn't change
    anything.
    =20
    Any hints?
    =20
    Thanks,
    =20
    Tino.
    =20
    PS: I found someone with a very similar problem: http://seclists.org/wireshark/2010/Jun/85 but no anwer nor solution (and
    he's getting Dup ACKs at least while I'm only seeing a DUP ACK after connection is closed.)
    =20
    --=20
    "What we nourish flourishes." - "Was wir n=E4hren erbl=FCht."
    =20
    www.tisc.de

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From anoopk6@gmail.com@1:0/0 to All on Wed Oct 2 09:23:02 2013
    Thanks . I will investigate the entropy parameter.

    Packet capture indicates that the following happens for more than 5 min=20

    client ------ Client Key Exchange ----------------------> Server
    client ------ Client Key Exchange(Re-transmission)------> Server
    client <----- ACK -------------------------------------- Server =20
    client ------ Client Key Exchange(Re-transmission)------> Server=20
    client <------ Dup ACK --------------------------------- Server
    client ------ Client Key Exchange(Re-transmission)------> Server=20
    client <------ Dup ACK --------------------------------- Server

    Anoop


    On Tuesday, 12 April 2011 21:12:16 UTC+5:30, Tino Schwarze wrote:
    Hi there,
    =20
    I'm currently chasing a rather weird problem. We've got a Java based
    program to connect to a Webshop (for importing/exporting data). Of
    course, we use SSL. (Webshop is on a webspace, client is behind DSL.)
    =20
    It used to work(tm) but somehow stopped working - the program could not access the Webshop anymore. Accessing by browser (from same machine)
    works.
    =20
    It's getting stranger... there's a proxy inbetween which is used by the
    Java app. I'm ssh-ing to the proxy machine (an OpenSUSE box, running
    kernel 2.6.27.56), I use lynx - it works. I use wget - it works.
    =20
    For testing, I made a very simple program which basically does
    =20
    new URL("https://my-url/").openConnection();
    =20
    and copies everything to stdout. Now the request just gets stuck.
    =20
    So I take a traffic dump, load it into Wireshark and see (sorry for the
    long lines):
    =20
    No. Time Source Destination Protocol =
    Size Info
    1 0.000000 212.80.cli.ent 188.40.t.srv TCP =
    74 49047 > https [SYN] Seq=3D0 Win=3D5840 Len=3D0 MSS=3D1460 SACK_PERM=
    =3D1 TSV=3D4228721087 TSER=3D0 WS=3D5
    2 0.031476 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D5840 Len=3D0 MSS=3D146=
    0 SACK_PERM=3D1 WS=3D6
    3 0.031527 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D1 Ack=3D1 Win=3D5856 Len=3D0
    4 0.219837 212.80.cli.ent 188.40.t.srv SSLv2 =
    166 Client Hello
    5 0.251510 188.40.t.srv 212.80.cli.ent TCP =
    60 https > 49047 [ACK] Seq=3D1 Ack=3D113 Win=3D5888 Len=3D0
    6 0.260881 188.40.t.srv 212.80.cli.ent TLSv1 =
    1514 Server Hello
    7 0.260919 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D1461 Win=3D8768 Len=3D0
    8 0.267468 188.40.t.srv 212.80.cli.ent TCP =
    1514 [TCP segment of a reassembled PDU]
    9 0.267506 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D2921 Win=3D11680 Len=3D0
    10 0.295676 188.40.t.srv 212.80.cli.ent TLSv1 =
    604 Certificate, Server Hello Done
    11 0.295715 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D3471 Win=3D14624 Len=3D0
    12 0.313933 212.80.cli.ent 188.40.t.srv TLSv1 =
    321 Client Key Exchange
    13 0.318689 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 Change Cipher Spec
    14 0.321350 212.80.cli.ent 188.40.t.srv TLSv1 =
    91 Encrypted Handshake Message
    15 0.353167 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D6912 Len=3D0 SLE=3D386=
    SRE=3D423
    16 0.582048 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    17 1.046053 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    18 1.974052 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    19 3.830055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    20 7.542049 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    21 14.966051 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    22 29.814055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    23 59.510067 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    24 70.992437 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [FIN, ACK] Seq=3D423 Ack=3D3471 Win=3D14624 Len=3D0
    25 71.023543 188.40.t.srv 212.80.cli.ent TCP =
    66 [TCP Dup ACK 15#1] https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D691=
    2 Len=3D0 SLE=3D386 SRE=3D424
    =20
    The FIN,ACK gets sent when I press CTRL-C to abort the program.
    =20
    I captured all traffic going to the server (tcpdump ... host 188.40.t.srv=
    ).
    It looks like the TCP session gets stuck at packet 13. I don't know
    where to look next or whom to ask.
    =20
    I checked that the following things work:
    - access $url via Browser, lynx and wget
    - access $url via said Java program via several other internet
    connections (other DSL providers, from other servers located at a
    certain hoster)
    =20
    After all, I can rule out:
    - fundamental Java/Server/SSL issue (because Java program works with
    same Java version on other system)
    - fundamental network issue (because other browsers work)
    =20
    Funny thing is, it worked once today - even though I didn't change
    anything.
    =20
    Any hints?
    =20
    Thanks,
    =20
    Tino.
    =20
    PS: I found someone with a very similar problem: http://seclists.org/wireshark/2010/Jun/85 but no anwer nor solution (and
    he's getting Dup ACKs at least while I'm only seeing a DUP ACK after connection is closed.)
    =20
    --=20
    "What we nourish flourishes." - "Was wir n=E4hren erbl=FCht."
    =20
    www.tisc.de

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Rick Jones@110:110/2002 to All on Wed Oct 2 16:28:28 2013
    anoopk6@gmail.com wrote:
    Thanks . I will investigate the entropy parameter.

    Packet capture indicates that the following happens for more than 5 min

    client ------ Client Key Exchange ----------------------> Server
    client ------ Client Key Exchange(Re-transmission)------> Server
    client <----- ACK -------------------------------------- Server
    client ------ Client Key Exchange(Re-transmission)------> Server
    client <------ Dup ACK --------------------------------- Server
    client ------ Client Key Exchange(Re-transmission)------> Server
    client <------ Dup ACK --------------------------------- Server

    What is the ACKnumber in the ACK from Server to client and how does
    that compare to the SEQuence number of the TCP segment carrying the
    Client Key Exchange? For that, "plain" tcpdump formatting rather than wireshark's (?) sometimes overly helpful formatting would be
    indicated. Are there checksum or other failures being reported in
    netstat -s?

    rick jones

    Anoop


    On Tuesday, 12 April 2011 21:12:16 UTC+5:30, Tino Schwarze wrote:
    Hi there,

    I'm currently chasing a rather weird problem. We've got a Java based program to connect to a Webshop (for importing/exporting data). Of
    course, we use SSL. (Webshop is on a webspace, client is behind DSL.)

    It used to work(tm) but somehow stopped working - the program could not access the Webshop anymore. Accessing by browser (from same machine)
    works.

    It's getting stranger... there's a proxy inbetween which is used by the Java app. I'm ssh-ing to the proxy machine (an OpenSUSE box, running
    kernel 2.6.27.56), I use lynx - it works. I use wget - it works.

    For testing, I made a very simple program which basically does

    new URL("https://my-url/").openConnection();

    and copies everything to stdout. Now the request just gets stuck.

    So I take a traffic dump, load it into Wireshark and see (sorry for the long lines):

    No. Time Source Destination Protocol
    Size Info
    1 0.000000 212.80.cli.ent 188.40.t.srv TCP
    74 49047 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=4228721087 TSER=0 WS=5
    2 0.031476 188.40.t.srv 212.80.cli.ent TCP
    66 https > 49047 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=6
    3 0.031527 212.80.cli.ent 188.40.t.srv TCP
    54 49047 > https [ACK] Seq=1 Ack=1 Win=5856 Len=0
    4 0.219837 212.80.cli.ent 188.40.t.srv SSLv2
    166 Client Hello
    5 0.251510 188.40.t.srv 212.80.cli.ent TCP
    60 https > 49047 [ACK] Seq=1 Ack=113 Win=5888 Len=0
    6 0.260881 188.40.t.srv 212.80.cli.ent TLSv1
    1514 Server Hello
    7 0.260919 212.80.cli.ent 188.40.t.srv TCP
    54 49047 > https [ACK] Seq=113 Ack=1461 Win=8768 Len=0
    8 0.267468 188.40.t.srv 212.80.cli.ent TCP
    1514 [TCP segment of a reassembled PDU]
    9 0.267506 212.80.cli.ent 188.40.t.srv TCP
    54 49047 > https [ACK] Seq=113 Ack=2921 Win=11680 Len=0
    10 0.295676 188.40.t.srv 212.80.cli.ent TLSv1
    604 Certificate, Server Hello Done
    11 0.295715 212.80.cli.ent 188.40.t.srv TCP
    54 49047 > https [ACK] Seq=113 Ack=3471 Win=14624 Len=0
    12 0.313933 212.80.cli.ent 188.40.t.srv TLSv1
    321 Client Key Exchange
    13 0.318689 212.80.cli.ent 188.40.t.srv TLSv1
    60 Change Cipher Spec
    14 0.321350 212.80.cli.ent 188.40.t.srv TLSv1
    91 Encrypted Handshake Message
    15 0.353167 188.40.t.srv 212.80.cli.ent TCP
    66 https > 49047 [ACK] Seq=3471 Ack=380 Win=6912 Len=0 SLE=386 SRE=423
    16 0.582048 212.80.cli.ent 188.40.t.srv TLSv1
    60 [TCP Retransmission] Change Cipher Spec
    17 1.046053 212.80.cli.ent 188.40.t.srv TLSv1
    60 [TCP Retransmission] Change Cipher Spec
    18 1.974052 212.80.cli.ent 188.40.t.srv TLSv1
    60 [TCP Retransmission] Change Cipher Spec
    19 3.830055 212.80.cli.ent 188.40.t.srv TLSv1
    60 [TCP Retransmission] Change Cipher Spec
    20 7.542049 212.80.cli.ent 188.40.t.srv TLSv1
    60 [TCP Retransmission] Change Cipher Spec
    21 14.966051 212.80.cli.ent 188.40.t.srv TLSv1
    60 [TCP Retransmission] Change Cipher Spec
    22 29.814055 212.80.cli.ent 188.40.t.srv TLSv1
    60 [TCP Retransmission] Change Cipher Spec
    23 59.510067 212.80.cli.ent 188.40.t.srv TLSv1
    60 [TCP Retransmission] Change Cipher Spec
    24 70.992437 212.80.cli.ent 188.40.t.srv TCP
    54 49047 > https [FIN, ACK] Seq=423 Ack=3471 Win=14624 Len=0
    25 71.023543 188.40.t.srv 212.80.cli.ent TCP
    66 [TCP Dup ACK 15#1] https > 49047 [ACK] Seq=3471 Ack=380 Win=6912 Len=0 SLE=386 SRE=424

    The FIN,ACK gets sent when I press CTRL-C to abort the program.

    I captured all traffic going to the server (tcpdump ... host
    188.40.t.srv).
    It looks like the TCP session gets stuck at packet 13. I don't know
    where to look next or whom to ask.

    I checked that the following things work:
    - access $url via Browser, lynx and wget
    - access $url via said Java program via several other internet
    connections (other DSL providers, from other servers located at a
    certain hoster)

    After all, I can rule out:
    - fundamental Java/Server/SSL issue (because Java program works with
    same Java version on other system)
    - fundamental network issue (because other browsers work)

    Funny thing is, it worked once today - even though I didn't change anything.

    Any hints?

    Thanks,

    Tino.

    PS: I found someone with a very similar problem: http://seclists.org/wireshark/2010/Jun/85 but no anwer nor solution (and he's getting Dup ACKs at least while I'm only seeing a DUP ACK after connection is closed.)

    --
    "What we nourish flourishes." - "Was wir n„hren erblht."

    www.tisc.de

    --
    I don't interest myself in "why." I think more often in terms of
    "when," sometimes "where;" always "how much." - Joubert
    these opinions are mine, all mine; HP might not want them anyway... :)
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: the Unofficial HP (110:110/2002@linuxnet)
  • From anoopk6@gmail.com@1:0/0 to All on Thu Oct 3 05:12:12 2013

    Client Key Exchange Seq=3D172 Ack=3D6515 Len=3D274
    ACK Seq=3D6515 Ack=3D446 Len=3D0=20

    Thanks
    Anoop


    On Tuesday, 12 April 2011 21:12:16 UTC+5:30, Tino Schwarze wrote:
    Hi there,
    =20
    I'm currently chasing a rather weird problem. We've got a Java based
    program to connect to a Webshop (for importing/exporting data). Of
    course, we use SSL. (Webshop is on a webspace, client is behind DSL.)
    =20
    It used to work(tm) but somehow stopped working - the program could not access the Webshop anymore. Accessing by browser (from same machine)
    works.
    =20
    It's getting stranger... there's a proxy inbetween which is used by the
    Java app. I'm ssh-ing to the proxy machine (an OpenSUSE box, running
    kernel 2.6.27.56), I use lynx - it works. I use wget - it works.
    =20
    For testing, I made a very simple program which basically does
    =20
    new URL("https://my-url/").openConnection();
    =20
    and copies everything to stdout. Now the request just gets stuck.
    =20
    So I take a traffic dump, load it into Wireshark and see (sorry for the
    long lines):
    =20
    No. Time Source Destination Protocol =
    Size Info
    1 0.000000 212.80.cli.ent 188.40.t.srv TCP =
    74 49047 > https [SYN] Seq=3D0 Win=3D5840 Len=3D0 MSS=3D1460 SACK_PERM=
    =3D1 TSV=3D4228721087 TSER=3D0 WS=3D5
    2 0.031476 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D5840 Len=3D0 MSS=3D146=
    0 SACK_PERM=3D1 WS=3D6
    3 0.031527 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D1 Ack=3D1 Win=3D5856 Len=3D0
    4 0.219837 212.80.cli.ent 188.40.t.srv SSLv2 =
    166 Client Hello
    5 0.251510 188.40.t.srv 212.80.cli.ent TCP =
    60 https > 49047 [ACK] Seq=3D1 Ack=3D113 Win=3D5888 Len=3D0
    6 0.260881 188.40.t.srv 212.80.cli.ent TLSv1 =
    1514 Server Hello
    7 0.260919 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D1461 Win=3D8768 Len=3D0
    8 0.267468 188.40.t.srv 212.80.cli.ent TCP =
    1514 [TCP segment of a reassembled PDU]
    9 0.267506 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D2921 Win=3D11680 Len=3D0
    10 0.295676 188.40.t.srv 212.80.cli.ent TLSv1 =
    604 Certificate, Server Hello Done
    11 0.295715 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D3471 Win=3D14624 Len=3D0
    12 0.313933 212.80.cli.ent 188.40.t.srv TLSv1 =
    321 Client Key Exchange
    13 0.318689 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 Change Cipher Spec
    14 0.321350 212.80.cli.ent 188.40.t.srv TLSv1 =
    91 Encrypted Handshake Message
    15 0.353167 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D6912 Len=3D0 SLE=3D386=
    SRE=3D423
    16 0.582048 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    17 1.046053 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    18 1.974052 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    19 3.830055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    20 7.542049 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    21 14.966051 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    22 29.814055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    23 59.510067 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    24 70.992437 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [FIN, ACK] Seq=3D423 Ack=3D3471 Win=3D14624 Len=3D0
    25 71.023543 188.40.t.srv 212.80.cli.ent TCP =
    66 [TCP Dup ACK 15#1] https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D691=
    2 Len=3D0 SLE=3D386 SRE=3D424
    =20
    The FIN,ACK gets sent when I press CTRL-C to abort the program.
    =20
    I captured all traffic going to the server (tcpdump ... host 188.40.t.srv=
    ).
    It looks like the TCP session gets stuck at packet 13. I don't know
    where to look next or whom to ask.
    =20
    I checked that the following things work:
    - access $url via Browser, lynx and wget
    - access $url via said Java program via several other internet
    connections (other DSL providers, from other servers located at a
    certain hoster)
    =20
    After all, I can rule out:
    - fundamental Java/Server/SSL issue (because Java program works with
    same Java version on other system)
    - fundamental network issue (because other browsers work)
    =20
    Funny thing is, it worked once today - even though I didn't change
    anything.
    =20
    Any hints?
    =20
    Thanks,
    =20
    Tino.
    =20
    PS: I found someone with a very similar problem: http://seclists.org/wireshark/2010/Jun/85 but no anwer nor solution (and
    he's getting Dup ACKs at least while I'm only seeing a DUP ACK after connection is closed.)
    =20
    --=20
    "What we nourish flourishes." - "Was wir n=E4hren erbl=FCht."
    =20
    www.tisc.de

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From anoopk6@gmail.com@1:0/0 to All on Mon Oct 21 13:26:32 2013

    Attaching wireshark screenshot http://img59.imageshack.us/img59/6431/p63e.p= ng.

    Anoop

    On Tuesday, 12 April 2011 21:12:16 UTC+5:30, Tino Schwarze wrote:
    Hi there,
    =20
    I'm currently chasing a rather weird problem. We've got a Java based
    program to connect to a Webshop (for importing/exporting data). Of
    course, we use SSL. (Webshop is on a webspace, client is behind DSL.)
    =20
    It used to work(tm) but somehow stopped working - the program could not access the Webshop anymore. Accessing by browser (from same machine)
    works.
    =20
    It's getting stranger... there's a proxy inbetween which is used by the
    Java app. I'm ssh-ing to the proxy machine (an OpenSUSE box, running
    kernel 2.6.27.56), I use lynx - it works. I use wget - it works.
    =20
    For testing, I made a very simple program which basically does
    =20
    new URL("https://my-url/").openConnection();
    =20
    and copies everything to stdout. Now the request just gets stuck.
    =20
    So I take a traffic dump, load it into Wireshark and see (sorry for the
    long lines):
    =20
    No. Time Source Destination Protocol =
    Size Info
    1 0.000000 212.80.cli.ent 188.40.t.srv TCP =
    74 49047 > https [SYN] Seq=3D0 Win=3D5840 Len=3D0 MSS=3D1460 SACK_PERM=
    =3D1 TSV=3D4228721087 TSER=3D0 WS=3D5
    2 0.031476 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D5840 Len=3D0 MSS=3D146=
    0 SACK_PERM=3D1 WS=3D6
    3 0.031527 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D1 Ack=3D1 Win=3D5856 Len=3D0
    4 0.219837 212.80.cli.ent 188.40.t.srv SSLv2 =
    166 Client Hello
    5 0.251510 188.40.t.srv 212.80.cli.ent TCP =
    60 https > 49047 [ACK] Seq=3D1 Ack=3D113 Win=3D5888 Len=3D0
    6 0.260881 188.40.t.srv 212.80.cli.ent TLSv1 =
    1514 Server Hello
    7 0.260919 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D1461 Win=3D8768 Len=3D0
    8 0.267468 188.40.t.srv 212.80.cli.ent TCP =
    1514 [TCP segment of a reassembled PDU]
    9 0.267506 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D2921 Win=3D11680 Len=3D0
    10 0.295676 188.40.t.srv 212.80.cli.ent TLSv1 =
    604 Certificate, Server Hello Done
    11 0.295715 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [ACK] Seq=3D113 Ack=3D3471 Win=3D14624 Len=3D0
    12 0.313933 212.80.cli.ent 188.40.t.srv TLSv1 =
    321 Client Key Exchange
    13 0.318689 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 Change Cipher Spec
    14 0.321350 212.80.cli.ent 188.40.t.srv TLSv1 =
    91 Encrypted Handshake Message
    15 0.353167 188.40.t.srv 212.80.cli.ent TCP =
    66 https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D6912 Len=3D0 SLE=3D386=
    SRE=3D423
    16 0.582048 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    17 1.046053 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    18 1.974052 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    19 3.830055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    20 7.542049 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    21 14.966051 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    22 29.814055 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    23 59.510067 212.80.cli.ent 188.40.t.srv TLSv1 =
    60 [TCP Retransmission] Change Cipher Spec
    24 70.992437 212.80.cli.ent 188.40.t.srv TCP =
    54 49047 > https [FIN, ACK] Seq=3D423 Ack=3D3471 Win=3D14624 Len=3D0
    25 71.023543 188.40.t.srv 212.80.cli.ent TCP =
    66 [TCP Dup ACK 15#1] https > 49047 [ACK] Seq=3D3471 Ack=3D380 Win=3D691=
    2 Len=3D0 SLE=3D386 SRE=3D424
    =20
    The FIN,ACK gets sent when I press CTRL-C to abort the program.
    =20
    I captured all traffic going to the server (tcpdump ... host 188.40.t.srv=
    ).
    It looks like the TCP session gets stuck at packet 13. I don't know
    where to look next or whom to ask.
    =20
    I checked that the following things work:
    - access $url via Browser, lynx and wget
    - access $url via said Java program via several other internet
    connections (other DSL providers, from other servers located at a
    certain hoster)
    =20
    After all, I can rule out:
    - fundamental Java/Server/SSL issue (because Java program works with
    same Java version on other system)
    - fundamental network issue (because other browsers work)
    =20
    Funny thing is, it worked once today - even though I didn't change
    anything.
    =20
    Any hints?
    =20
    Thanks,
    =20
    Tino.
    =20
    PS: I found someone with a very similar problem: http://seclists.org/wireshark/2010/Jun/85 but no anwer nor solution (and
    he's getting Dup ACKs at least while I'm only seeing a DUP ACK after connection is closed.)
    =20
    --=20
    "What we nourish flourishes." - "Was wir n=E4hren erbl=FCht."
    =20
    www.tisc.de

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Jamma Tino Schwarze@110:110/2002 to All on Thu Oct 24 15:05:00 2013
    anoopk6@gmail.com wrote:

    Attaching wireshark screenshot
    http://img59.imageshack.us/img59/6431/p63e.png.

    Yup, that looks exactly like the issue I was describing two years ago.
    Did you check the kernel entropy pool?
    /proc/sys/kernel/random/entropy_avail ?

    Jamma.

    On Tuesday, 12 April 2011 21:12:16 UTC+5:30, Tino Schwarze wrote:
    Hi there,

    I'm currently chasing a rather weird problem. We've got a Java based
    program to connect to a Webshop (for importing/exporting data). Of
    course, we use SSL. (Webshop is on a webspace, client is behind DSL.)

    It used to work(tm) but somehow stopped working - the program could not
    access the Webshop anymore. Accessing by browser (from same machine)
    works.

    It's getting stranger... there's a proxy inbetween which is used by the
    Java app. I'm ssh-ing to the proxy machine (an OpenSUSE box, running
    kernel 2.6.27.56), I use lynx - it works. I use wget - it works.

    For testing, I made a very simple program which basically does

    new URL("https://my-url/").openConnection();

    and copies everything to stdout. Now the request just gets stuck.

    So I take a traffic dump, load it into Wireshark and see (sorry for the
    long lines):

    No. Time Source Destination Protocol Size Info
    1 0.000000 212.80.cli.ent 188.40.t.srv TCP 74
    49047 > https [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=4228721087 TSER=0 WS=5
    2 0.031476 188.40.t.srv 212.80.cli.ent TCP 66
    https > 49047 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=6
    3 0.031527 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [ACK] Seq=1 Ack=1 Win=5856 Len=0
    4 0.219837 212.80.cli.ent 188.40.t.srv SSLv2 166 Client Hello
    5 0.251510 188.40.t.srv 212.80.cli.ent TCP 60
    https > 49047 [ACK] Seq=1 Ack=113 Win=5888 Len=0
    6 0.260881 188.40.t.srv 212.80.cli.ent TLSv1 1514 Server Hello
    7 0.260919 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [ACK] Seq=113 Ack=1461 Win=8768 Len=0
    8 0.267468 188.40.t.srv 212.80.cli.ent TCP 1514 [TCP segment of a reassembled PDU]
    9 0.267506 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [ACK] Seq=113 Ack=2921 Win=11680 Len=0
    10 0.295676 188.40.t.srv 212.80.cli.ent TLSv1 604 Certificate, Server Hello Done
    11 0.295715 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [ACK] Seq=113 Ack=3471 Win=14624 Len=0
    12 0.313933 212.80.cli.ent 188.40.t.srv TLSv1 321 Client Key Exchange
    13 0.318689 212.80.cli.ent 188.40.t.srv TLSv1 60
    Change Cipher Spec
    14 0.321350 212.80.cli.ent 188.40.t.srv TLSv1 91
    Encrypted Handshake Message
    15 0.353167 188.40.t.srv 212.80.cli.ent TCP 66
    https > 49047 [ACK] Seq=3471 Ack=380 Win=6912 Len=0 SLE=386 SRE=423
    16 0.582048 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    17 1.046053 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    18 1.974052 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    19 3.830055 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    20 7.542049 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    21 14.966051 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    22 29.814055 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    23 59.510067 212.80.cli.ent 188.40.t.srv TLSv1 60
    [TCP Retransmission] Change Cipher Spec
    24 70.992437 212.80.cli.ent 188.40.t.srv TCP 54
    49047 > https [FIN, ACK] Seq=423 Ack=3471 Win=14624 Len=0
    25 71.023543 188.40.t.srv 212.80.cli.ent TCP 66
    [TCP Dup ACK 15#1] https > 49047 [ACK] Seq=3471 Ack=380 Win=6912 Len=0 SLE=386 SRE=424

    The FIN,ACK gets sent when I press CTRL-C to abort the program.

    I captured all traffic going to the server (tcpdump ... host 188.40.t.srv). >> It looks like the TCP session gets stuck at packet 13. I don't know
    where to look next or whom to ask.

    I checked that the following things work:
    - access $url via Browser, lynx and wget
    - access $url via said Java program via several other internet
    connections (other DSL providers, from other servers located at a
    certain hoster)

    After all, I can rule out:
    - fundamental Java/Server/SSL issue (because Java program works with
    same Java version on other system)
    - fundamental network issue (because other browsers work)

    Funny thing is, it worked once today - even though I didn't change
    anything.

    Any hints?

    Thanks,

    Tino.

    PS: I found someone with a very similar problem:
    http://seclists.org/wireshark/2010/Jun/85 but no anwer nor solution (and
    he's getting Dup ACKs at least while I'm only seeing a DUP ACK after
    connection is closed.)

    --
    "What we nourish flourishes." - "Was wir n„hren erblht."

    www.tisc.de

    --
    "What we nourish flourishes." - "Was wir n„hren erblht."

    www.tisc.de

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: Individual Network Chemnitz, FRG (110:110/2002@linuxnet)
  • From anoopk6@gmail.com@1:0/0 to All on Fri Oct 25 06:50:22 2013
    I checked entropy.

    Latest news is that the problem disappeared after removing a firewall in th=
    e network. But I am still curious as to how a TCP transaction can go in to = this re transmit loop (as seen in wireshark screenshot) assuming there is a=
    firewall in between. Why client is retransmitting same packet again even a= fter receiving ACK from server ?

    --- MBSE BBS v1.0.0 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb