On 23 May 2002, alex wrote:
>
> Hi all,
>
> I'm looking for people who have download problems where they can't
> download certain files or from certain sites. I've never been able to
> reproduce the problem and it does seem apparent that different people
> running the same code can get different results.
>
> My theory/hunch/wild guess is based on the observation that some people
> have noted CRC errors whilst these downloads are happening. We really
> shouldn't see CRC errors that often (especially at the rates most people
> are running at) so if your having problems could you try applying this
> patch:
>
Just a note of warning. Alex's patch is _likely_ to end up with a coredump
if the CRC errors are genuine. (I would expect to see a coredump within
about 200-500 bad packets)
I can guess what Alex is thinking but I suspect dodgy USB hardware. I can
now reliably trigger my problem after an investigation of what it was that
was the problem. On my machine it is after a number of packets that contain
only 0xff data - note that not every byte contains 0xff because the ATM
framing data is still there. I suspect similar bit patterns are tripping up
other peoples hardware as well.
(For me, the magic file I couldn't download was the php-manual update rpm
from ftp.mirror.ac.uk. However, I could sometimes download it direct from
RedHat - I suspect that the transatlantic link was adding enough delay
to avoid the problem)
This patch has fixed my stability problems (at the cost of speed). Using
async also seems to be a little more stable for me.
[tim@pauli /home/tim/cvs/speedtouch]$ cvs diff 2>/dev/null | grep -v "^?"
Index: src/pppoa3.c
===================================================================
RCS file: /cvsroot/speedtouch/speedtouch/src/pppoa3.c,v
retrieving revision 1.24
diff -u -r1.24 pppoa3.c
--- src/pppoa3.c 18 May 2002 19:54:46 -0000 1.24
+++ src/pppoa3.c 23 May 2002 20:37:56 -0000
@@ -849,6 +849,7 @@
/* Reads 64*53 bytes from usb */
do {
+ usleep(900);
n = pusb_endpoint_read(ep_data, lbuf, sizeof(lbuf), 0);
} while (n < 0 && (errno == EINTR || errno == ETIMEDOUT));
@@ -888,6 +889,7 @@
/* Writes the result buffer */
if(ppp_write(STDOUT_FILENO, ppp_write_buf, n +
HDLC_HEADER_SIZE) > 0)
report(2, REPORT_DEBUG|REPORT_DATE, "Extracted
PPP packet sent to ppp(d)\n\n");
+ usleep(100);
}
> alex@trent speedtouch]$ cvs diff -u src/atm.c
> Index: src/atm.c
> ===================================================================
> RCS file: /cvsroot/speedtouch/speedtouch/src/atm.c,v
> retrieving revision 1.6
> diff -u -r1.6 atm.c
> --- src/atm.c 21 Mar 2002 23:35:43 -0000 1.6
> +++ src/atm.c 23 May 2002 18:04:46 -0000
> @@ -390,9 +390,10 @@
> frame_crc =
> data[length-4]<<24|data[length-3]<<16|data[length-2]<<8|data[length-1];
>
> /* If not equal the aal5 frame is corrupted */
> - if(computed_crc != frame_crc)
> + /* if(computed_crc != frame_crc)
> return(-1);
> -
> + */
> +
> /* Find the real len */
> real_length = (((int)frame[length - 6])<<8)|((int)frame[length - 5]);
>
> Which disables the CRC check. Recompile, re-install pppoa3 and shutdown
> and re-connect to your ISP. I'm interested in feedback so please
> indicate:
>
> 1. Version of driver (I assume everyone is on 1.1rc2 by now :-)
> 2. md5sum of your microcode file
> 3. URL of file you where having a problem with
> 4. How far along the download would the file get (to the byte please)
> 5. Did the patch make a difference?
> 6. If so the md5sum of the downloaded file (so I can compare and check)
>
> For bonus point anyone willing to grab a tcpdump or ethereal dump would
> be great (but don't post it to the list, I'll contact you).
>
>
>
--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.
http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/
Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se d�sinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
