speedtouch  

[speedtouch] Re: Speedtouch reliability and performance

jazbo
Sat, 27 Apr 2002 13:45:48 -0700

Tim Woodall wrote:

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

What chipset do you have may I ask ?
My USB is provided by a 1996 IBM pc350 pentium 166.  specifically:
00:01.2 USB Controller: Intel Corp. 82371SB PIIX3 USB [Natoma/Triton II] 
(rev 01)
So it's an old but very common UHCI usb chipset. I haven't any idea if 
it's supposed to be difficult or not. This is the only usb item attached 
to it.

If anyone knows that the usb support of IntelPIIX3  chipsets of the 1996 
vintage to be  buggy, and they also of a perfectly supported bugfree usb 
board please tell me in either case. USB boards aren't expensive but 
this dsl problem is costing me a lot of pulled out hair. If there's even 
a chance that flakey usb support is contributing partially to my problem 
I'd like to know and I'd be quick to buy a good usb board to eliminate 
that contribution. I've never heard of a usb board that was good to use 
with Linux, so I've never given alot of thought to this possible side of 
the problem.

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





Liste de diffusion modem ALCATEL SpeedTouch USB
Pour se désinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe