On Tue, Feb 8, 2011 at 7:01 PM, Tolas Anon <tolas777@xxxxxxxxx> wrote:
> Things I've checked in the meanwhile;
>
> curl_setopt($ch,CURLOPT_TIMEOUT, 0); and
> curl_setopt($ch,CURLOPT_TIMEOUT, 99999); have the same freezing
> results as before
>
> I've used a packetsniffer to analyze the dataflow on my port 80, with
> all other http apps incl the browser not in memory/running, so i could
> get a clear view.
> Turns out i do get the traffic my php_daemon_script relies on and
> should get from curl_exec() when the 2gb video file has finished
> converting & importing, flowing from an 192.xyz.xyz.xyz address (which
> is my apache) to a 82.xyz.xyz.xyz address (also resolves to my
> apache).
>
> I currently run the entire site, upload and import on the same machine
> and instance of apache.
> And the import was run from that windows.bat again, which i had
> running as a normal dos window.
> I made sure the sniffer caught both the initialization of the
> offending 2gb-convert call, and it's termination, which i monitored by
> monitoring the server filesystem (the size of the converted vid, and
> the fact it got moved into it's final directory for serving to the
> end-user).
>
> This apache installation is on an adsl modem that does
> outside-to-inside port 80 forwarding to my windows apache
> installation, and i use the outside-world domain name linked to my
> adsl IP for the site and upload and import.
>
> However, this "wanted" traffic is reported by wireshark (the sniffer)
> as having an invalid 0x0000 header checksum, which should be
> "something else" (a hex value of course).
> The packet flow is like this:
> 192... -> 82... : HTTP/1.1 200 OK (text/html) {wanted data}
> 192... -> 82... : RETRANSMISSION HTTP/1.1 200 OK (text/html) {wanted data}
> 192... -> 82... : HTTP > portno [FIN,ACK] seq=... ack=... win=..... len=0
> 192... -> 82... : RETRANSMISSION HTTP/1.1 200 OK (text/html) {wanted data}
> 192... -> 82... : RETRANSMISSION HTTP/1.1 200 OK (text/html) {wanted data}
> 192... -> 82... : RETRANSMISSION HTTP/1.1 200 OK (text/html) {wanted data}
> 192... -> 82... : RETRANSMISSION HTTP/1.1 200 OK (text/html) {wanted data}
> 192... -> 82... : HTTP > portno [RST,ACK] seq=... ack=... win=0 len=0
> After this the http capturing goes silent again.
>
> The wanted packet does not show up in the debug-info-to-file call made
> by the php_daemon_script just after it does
> $result=curl_exec(valid-settings);
>
> I don't use sniffers often, so i have to ask;
>
> Is this enough evidence to report it as a libcurl bug?
> Or do i have to suspect php-cli and cmd.exe as well?
>
>
>
> P.S.;
> Entire WAMP installed by WampServer2.1d-x64.exe
> PHP Version 5.3.4
>
> System Windows NT NOOT 6.1 build 7600 (Unknow Windows version Home
> Premium Edition) AMD64
> Build Date Dec 15 2010 23:40:06
> Compiler MSVC9 (Visual C++ 2008)
> Architecture x64
>
> libcurl-7.21.3.0 added manually
>
I've been thinking about that reported bad checksum. libcurl may be
right to reject those packets.
And i guess that apache determines that 0x0000 checksum.
That is, _if_ i can trust the accuracy of that wireshark app.
Bit too many variables at work here for my liking, but this bug just
has to get fixed.
I guess i'll un-install wireshark, install a different sniffer app and
re-do the whole thing, i'll let you know the results when they are in.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
