[sync] how to debug activesync "connection" problems

[Stephan Lauffer]

Hi!

Am 21.02.2012 19:13, schrieb Michael J Rubinsky:
>
> Quoting Stephan Lauffer <lauffer at ph-freiburg.de>:
>
>> Hello!
>>
>> I try to eval and test the ActiveSync part in horde. Therefore I have
>> a 4.0.13 horde environment (groupware... imp) on a apache2-2.2.12 with
>> php5-5.2.14.
>>
>> IMHO all needed prerequirements are fulfilled - test.php looks good so
>> far.
>>
>> The client ActiveSync part I would like to try with a android 2.3.6 atm.
>>
>> My problem right now seems to be very early in ActiveSync connection:
>>
>> If I try to connect with the droid it ends up in a apache ssl log...
>>
>> ...TLSv1 RC4-MD5 "OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1" - "-"
>> "Moto-MB526/4.5.1"
>>
>> (big eyes on OPTIONS)
>
> This is an expected, and required, request.
>
>>
>> and for this the access log just gives me a 200:
>>
>> ..."OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1" 200 -
>>
>> But nothing else happened. So I put in rpc.php as first cmd
>>
>> system("touch /tmp/I-was-there");
>>
>> ...and I got the information: I never was there(!)
>>
>> So I played around with all redirect and alias settings from our wiki
>> page but nothing helped.
>
> rpc.php is the *very* first bit of Horde code that an ActiveSync request
> would hit. If it's never reaching line 1 of rpc.php then something is
> broken with your server configuration.

I know...exactely because of this I added the system() there.

>> If I give it a try with a browser - just to see if something general
>> seems to be wrong - I can access rpc.php. The log looks different and
>> now I see the well known and expected...
>
> The difference is that this will be a GET request, not the required
> initial OPTIONS request. Perhaps something is broken on your webserver
> regarding OPTIONS?
>
>
>> ...ssl log:
>>
>> ...TLSv1 DHE-RSA-CAMELLIA256-SHA "GET /Microsoft-Server-ActiveSync
>> HTTP/1.1" 71 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0)
>> Gecko/20100101 Firefox/10.0"
>>
>> common:
>>
>> ..."GET /Microsoft-Server-ActiveSync HTTP/1.1" 500 71
>>
>> ...which ended in a expected 500 caused by rpc.php ("Trying to access
>> the ActiveSync endpoint from a browser. Not Supported."). And yes now
>> I get the "I-was-there" file touched in /tmp.
>>
>> I assume something mysti with the http option request. f.e. I found
>> something like this
>> http://technet.microsoft.com/en-us/library/dd439384%28v=exchg.80%29.aspx
>
> No. That is describing an issue when the EAS server does not include the
> required *response* headers. Our response headers are only sent out
> after rpc.php processes the request. As stated above, if you are 100%
> sure you are never hitting rpc.php, then something is broken with your
> server or configuration.

Ok, good to know.

>
>> So... does anybody know something more?
>>
>> Right know I can't sniff http since the droid only accepts https. Maybe
>
> Really? What device/carrier is this? I've never seen a droid - or any
> device for that matter - that would not connect to EAS over plain http
> (assuming the http port is available to answer the requests).

I was wrong. I had an redirect port 80 tcp to 443 on serverside. So I 
was able to sniff, see my second (last) mail.

>> I need to load/unload/configure some apache further modules to get
>> this problem fixed?
>
> Not that I know of/can think of, though I'm more of a lighttpd person
> myself.

Ok, so any apache feedback is welcome!

Right now I just know that a common get request caused by a browser ends 
in rpc.php and the one caused by my droid fails before... I will have a 
closer look to my network captured data.

I hoped someone had similar problems.