[speedtouch] Re: Speedtouch reliability and performance

[Tim Woodall]

On 27 Apr 2002, alex wrote:

> 
> On Fri, 2002-04-26 at 19:32, jazbo wrote:
<snip>
> 
> > The connection dies on high speed transfers. I can surf and chat, but 
> > downloads of large files from fast servers can cause my connection to 
> > die. Is this something others experience as well?
> 
> Have you got the logs for these deaths. Some people have reported the
> certain files can kill the connection but It always proved difficult to
> tie it down. Is it any long file or just dertain ones?
> 
I have this problem. I have narrowed it down (on my connection) to
files with long streams of 0xff. Ed Gomez thinks it is probably a
buggy USB chipset (and I am inclined to agree with him)

The following patch fixes it for me (at the cost of reducing my
maximum download rate to about 35k/sec rather than 58k/sec. I am running
with this patch as I want reliability over bandwidth and I also schedule
downloads for the middle of the night. (one day I will go out and buy a
pci USB card but I'm lazy ;-)


[tim@pauli /home/tim/cvs/speedtouch/src]$ cvs diff pppoa3.c
Index: pppoa3.c
===================================================================
RCS file: /cvsroot/speedtouch/speedtouch/src/pppoa3.c,v
retrieving revision 1.23
diff -u -r1.23 pppoa3.c
--- pppoa3.c    18 Apr 2002 19:46:28 -0000      1.23
+++ pppoa3.c    27 Apr 2002 11:17:10 -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);

                        }



> There was a small bug in the aal5 code in pppoa3 but I'm not sure how
> often it triggered. You could always try the latest CVS. We might even
> get around to releasing 1.1 soon.
> 
I don't think this bug really mattered, certainly I haven't seen any
difference.

(Incidently there is another bug in atm.c - right at the end of the file.

We verify that the CRC value for the frame is correct but then use
the real_length from the frame without checking that it is a valid
length.

This will never be tripped in real life - about 1 in 4 billion _incorrect_
frames, i.e. if you see one CRC error per second you would have to wait
about 100 years before this bug would happen

However, a rogue ISP employee could possibly exploit it by crafting
frames that had a valid CRC but an invalid length and use this to
overwrite about 64K of the heap.

I think the correct check before the if(data != frame) line should
be (untested)

if(real_length>length-8 || real_length<=length-8-ATM_CELL_DATA_SIZE)
    return -1;

(The second test is not strictly necessary but IIRC there is only allowed
to be up to ATM_CELL_DATA_SIZE-1 bytes of padding in a frame)


I haven't tried this patch as I consider it a theoretical rather than a
real risk but it probably ought to be fixed ;-)

Regards,

Tim.

-- 
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