Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of pon.umapathy@gmail.com
 designates 74.125.82.45 as permitted sender)
MIME-Version: 1.0
Date: Thu, 16 Oct 2014 11:26:10 +0530
Message-ID: 
 <CAEqv1uDoTFWrHBD80k=fn5L-zjnEfCbVcuWkz61m3_hu0xgZdA@mail.gmail.com>
Subject: debugging ssl packet drop
From: Pon Umapathy Kailash S <pon.umapathy@gmail.com>
To: modules-dev@httpd.apache.org
Content-Type: text/plain; charset=UTF-8

Hi,
 I am facing the an issue where a SSL packet from IE10 doesn't reach
the client processing thread for a particular connection(more details
below).  Can you please provide me pointers on where to look/add more
debug logs in the code to figure out what's happening? We use mpm
worker threads.

I have added support for websockets in a customised manner(as required
for our application) inside apache. At a high level, it's done as
follows:

- the initial GET request with 101 code is handled by a handler hook
function which computes the required security keys and sends back the
response. Also, the socket on which the request came in is not
closed(by maintaining a list and patching some parts of the apache
code to not close if a socket is present in this list).

- the child thread which processes this connection will relinquish the
connection after the keep-alive timeout , which is ok since all we
need is for the server to send messages to the client, with one
exception.

- At this point, the socket is recognised as a websocket client which
is not yet authenticated(since from browsers we cannot set custom
headers with the initial websocket connection request).

- Authentication is done by the client sending the cookie as the
1st(and only) message on this connection to the server within the
keep-alive timeout period(at which point the cookie is authenticated
and the socket is marked as a valid, authenticated subscriber).
(* there are other functions/timers to take care of stale, unauth
connections etc)

This works fine in all browsers with support for websockets with the
following exceptions:

IE10 over ssl(https/wss) and IE11 over ssl on 32-bit client machines.

Doing a packet capture, we could figure out that the initial
connection goes through fine and when the cookie is sent from the
client, it reaches the server(and there's a tcp ack received at the
client for this packet). However, the client processing this
connection doesn't seem to receive this packet(this is well within the
keep alive interval and the client thread is still actively processing
that connection).

Can you please let me know at which points in the code flow it might
be useful to add debugging info to see where this is getting dropped?

Regards,
Umapathy