[speedtouch] Re: FreeBSD problems + some fixes.
David Hedley ([EMAIL PROTECTED]) wrote: > > 2) pppoa2 freezes under heavy load. > > I use the excellent userland ppp which uses pppoa2. Under heavy load, > the pppoa2 process which reads from the USB hangs in > pusb_endpoint_read in pusb-bsd.c. This will normally be observed as an > LQR timeout in the upper PPP layer (assuming you enable LQR). I'm not > sure why this is happening. The only way I've found to unwedge it is > to send the pppoa2 process a signal. To this end, the following patch > uses a watchdog timer to ensure the process doesn't get wedged: Well we are experimenting similar problems with GNU/Linux pppoa3 (well it's posix compliant but for an unknown reason, it still doesn't work with BSD systems). The daemon hangs in a pusb_endpoint_read. But we have noticed this bug occurs when using a buggy usb chipset. But we are not sure. Special sequences of bytes seems to hang up the pppoa slave in a usb read ioctl, just like you. So this is a problem in the way we use the usb or the kernel usb implementation. > 3) Heavy usages causes large amounts of bad data to be read from the USB. In the >logs this looks like: > > Jul 3 13:58:35 exoserver pppoa2[6631]: Cell had wrong VPI(4068)/VCI(31234) (OAM?) >PTI=0x06 > [...] > > Not sure why this is happening - it doesn't seem to affect throughput > that much but is quite noisy. It seems to result from a read from > pusb_endpoint_read which returns a non-integer number of ATM > cells. This looks to me like a synchronisation/locking issue between > the read syscall in pppoa2 and the USB subsystem. You're right, the modem is supposed to give us atm cells, so we expect an integer number of cells in our little atm stack implementation. I should have write it again to make it more robust, but i'm actually very lazy. But for sure i'll write a new atm stack before September. This kind of things would not occur anymore if i do the code more complete (the current code is small and very fast, i think it could even be fooled by wrong atm cells - DoS - Attack ?) > 4) Random kernel panics > > This is the most disturbing bug of the lot. It looks like there's some > memory corruption happening inside the USB subsystem that occasionally > causes random kernel panics - the panic will typically occur as a > fatal trap inside kernel malloc. Good luck to anyone attempting to > track that one down Well as the driver is userland, the kernel panic must be caused by the kernel code itself. And as you say... "Good luck to anyone attempting to track that one down" Btw i'll have a look at all your patches (not the kernel one) to update both pppoa3 and pppoa2. -- Edouard Gomez Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
[speedtouch] Re: FreeBSD problems + some fixes.
On Wed, 3 Jul 2002, David Hedley wrote: > > > I have been extensively testing the Speedtouch USB modem under > FreeBSD (currently 4.4, will be testing 4.6 soon) with the latest > (161.5R) alcaudsl.sys from Alcatel and the 1.1 drivers from this > site. > > I have noticed the following problems: > > > 2) pppoa2 freezes under heavy load. > > I use the excellent userland ppp which uses pppoa2. Under heavy load, > the pppoa2 process which reads from the USB hangs in > pusb_endpoint_read in pusb-bsd.c. This will normally be observed as > an LQR timeout in the upper PPP layer (assuming you enable LQR). I'm > not sure why this is happening. The only way I've found to unwedge it > is to send the pppoa2 process a signal. To this end, the following > patch uses a watchdog timer to ensure the process doesn't get wedged: > I get this with pppoa3 on linux. Same place in the code. I will try your fix. (The thing that trips it reliably for me is downloading a 64K or so file consisting entirely of 0xFF via FTP.) > (You can ignore the first part to this patch - I just don't like rude > words being written to the logs!) > > 3) Heavy usages causes large amounts of bad data to be read from the > USB. In the logs this looks like: > > Jul 3 13:58:35 exoserver pppoa2[6631]: Cell had wrong VPI(4068)/VCI(31234) (OAM?) >PTI=0x06 > Jul 3 13:58:41 exoserver pppoa2[6631]: Cell had wrong VPI(3240)/VCI(48850) (OAM?) >PTI=0x04 > Jul 3 13:58:48 exoserver pppoa2[6631]: Cell had wrong VPI(981)/VCI(44053) (OAM?) >PTI=0x05 > Jul 3 13:58:49 exoserver pppoa2[6631]: Cell had wrong VPI(1447)/VCI(31788) (OAM?) >PTI=0x00 > Jul 3 13:59:05 exoserver pppoa2[6631]: Cell had wrong VPI(2948)/VCI(3831) (OAM?) >PTI=0x03 > Jul 3 13:59:05 exoserver pppoa2[6631]: CRC error in an AAL5 frame > Jul 3 13:59:26 exoserver pppoa2[6631]: Cell had wrong VPI(1251)/VCI(55468) (OAM?) >PTI=0x06 > Jul 3 13:59:31 exoserver pppoa2[6631]: Cell had wrong VPI(671)/VCI(4876) (OAM?) >PTI=0x07 > > Not sure why this is happening - it doesn't seem to affect throughput that much but >is quite noisy. It seems to result from a read from pusb_endpoint_read which returns >a non-integer number of ATM cells. This looks to me like a synchronisation/locking >issue between the read syscall in pppoa2 and the USB subsystem. > There is definitely a bug in the bit of code that rebuilds the ppp packet from the atm frame where it calculates the length. in aal5_frame_dec if the CRC check passes we rely on the length being correct in the packet. This _might_ be exploitable but won't be a standard "stack smashing" attack if so. However, AFAICT, only someone with the ability to craft corrupt ATM frames and get them delivered to pppoa[23] could exploit it which I think limits it to people with access to the ATM equipment at the exchange. (I don't think it can be exploited to give remote access/run remote commands but it could possibly be used to sniff network traffic remotely by sending a corrupted echo_request packet which would then reply with the data that was previously read from the frog. Of course, if someone has access to the equipment at the exchange then this seems like a somewhat tortuous route to sniff the traffic :-) Regards, Tim. p.s. any chance you can configure your mail client to limit its lines to circa 72 characters please. -- 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
[speedtouch] Re: FreeBSD problems + some fixes.
In an exciting post with subject [speedtouch] Re: FreeBSD problems + some fixes., "Tim Woodall" <[EMAIL PROTECTED]> wrote: > On Wed, 3 Jul 2002, David Hedley wrote: > > 2) pppoa2 freezes under heavy load. I am running 4.6-STABLE FreeBSD 4.6-STABLE #5: Wed Jul 3 17:46:04 CEST 2002 and I got the same problem. > (The thing that trips it reliably for me is downloading a 64K or so > file consisting entirely of 0xFF via FTP.) My experiments reveal the problem when uploading, ie some friends getting huge files via ftp from my server, reaching the 16Ko/s upload bandwith limit. But no problem whith downloads... Any idea ? I am trying David's fix in the code, we'll see... -- TCHO Jeff --- FreeBSD : The power to serve ! See http://meuleu.homeunix.org Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
[speedtouch] Re: FreeBSD problems + some fixes.
Really noddy question time...
How do I recompile the usb0/uhci0 drivers? Do I have to do a make world
etc for that, or is there a way I can sneak in just the changes?
Matthew.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of David Hedley
Sent: 03 July 2002 14:18
To: [EMAIL PROTECTED]
Subject: [speedtouch] FreeBSD problems + some fixes.
I have been extensively testing the Speedtouch USB modem under FreeBSD
(currently 4.4, will be testing 4.6 soon) with the latest (161.5R)
alcaudsl.sys from Alcatel and the 1.1 drivers from this site.
I have noticed the following problems:
1) The USB controller halts with:
usb0: host controller process error
usb0: host controller halted
This appears to be an underlying problem with the FreeBSD USB subsystem
and is not just limited to using the speedtouch drivers. Stressing the
USB appears to make this problem increase in frequency.
I'm still investigating why this is happening and what can be done about
it. For the moment, the following patch re-enables the USB subsystem.
Providing you're using usbd to run modem_run, the following fix will
result in only about 30 seconds downtime for the ADSL:
*** /usr/src/sys/dev/usb/uhci.c Tue Oct 31 23:23:29 2000
--- uhci.c Wed Jul 3 13:53:16 2002
***
*** 962,970
--- 962,990
USBDEVNAME(sc->sc_bus.bdev));
}
if (status & UHCI_STS_HCH) {
+ int s;
+
/* no acknowledge needed */
printf("%s: host controller halted\n",
USBDEVNAME(sc->sc_bus.bdev));
+
+ /* Try to restart */
+ printf("DCRH: Restarting USB controller\n");
+ s = splusb();
+ sc->sc_bus.use_polling++; /* Switch to polling in case
curproc=NULL */
+
+ UWRITE2(sc, UHCI_STS, 0x); /* ack pending
interrupts */
+ uhci_run(sc, 0);/* stop the controller
*/
+ UWRITE2(sc, UHCI_INTR, 0); /* disable interrupts */
+ uhci_busreset(sc);
+ UWRITE2(sc, UHCI_INTR, UHCI_INTR_TOCRCIE | UHCI_INTR_RIE
|
+ UHCI_INTR_IOCE | UHCI_INTR_SPIE); /*
enable interrupts */
+ UHCICMD(sc, UHCI_CMD_MAXP); /* Assume 64 byte packets at
frame end */
+ uhci_run(sc, 1); /* and here we go... */
+ sc->sc_bus.use_polling--;
+ splx(s);
+ ack = 0;
+ printf("DCRH: USB controller restarted\n");
}
if (ack)/* acknowledge the ints */
2) pppoa2 freezes under heavy load.
I use the excellent userland ppp which uses pppoa2. Under heavy load,
the pppoa2 process which reads from the USB hangs in pusb_endpoint_read
in pusb-bsd.c. This will normally be observed as an LQR timeout in the
upper PPP layer (assuming you enable LQR). I'm not sure why this is
happening. The only way I've found to unwedge it is to send the pppoa2
process a signal. To this end, the following patch uses a watchdog timer
to ensure the process doesn't get wedged:
*** speedtouch-1.1-orig/src/pppoa2.cSat Jun 1 00:34:25 2002
--- speedtouch-1.1/src/pppoa2.c Wed Jul 3 13:58:14 2002
***
*** 366,372
if(fdusb == NULL)
{
! report(0, REPORT_ERROR|REPORT_DATE, "Where is
this crappy modem ?!\n");
return(-1);
}
--- 366,372
if(fdusb == NULL)
{
! report(0, REPORT_ERROR|REPORT_DATE, "Where is
this modem ?!\n");
return(-1);
}
***
*** 770,775
--- 770,781
}
#endif
+ volatile int timeouts = 0;
+ void watchdog(int s)
+ {
+ timeouts++;
+ }
+
/*
* Function : handle_endpoint_87
* Return Values : none
***
*** 801,823
--- 807,847
/* Prepares pos */
pos = 0;
+ signal(SIGALRM, watchdog);
+
/* Reads from usb and writes to ppp(d) tty */
for(;;) {
+ struct itimerval tv_timeout = {
+ { 0, 50 }, /* 1/2 second */
+ { 0, 50 },
+ };
+ struct itimerval tv_zero = {
+ { 0, 0 },
+ { 0, 0 },
+ };
int n;
int pti;
unsigned char lbuf[64*53];
unsigned char *unused_cells;
+ setitimer(ITIMER_REAL, &tv_timeout, NULL); /*
Watchdog timer */
+
/* Reads 64*53 bytes from usb */
do {
n = pusb_endpoint_read(epdata, lbuf,
sizeof(lbuf), 0);
[speedtouch] Re: FreeBSD problems + some fixes.
In an exciting post with subject [speedtouch] Re: FreeBSD problems + some fixes., "Matthew Smalley" <[EMAIL PROTECTED]> wrote: > How do I recompile the usb0/uhci0 drivers? Do I have to do a make > world etc for that, or is there a way I can sneak in just the changes? uhci driver is part of the kernel, ie re-building the kernel will do the job. You may wish to read the handbook which is always a good documentation : http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html -- TCHO Jeff --- FreeBSD : The power to serve ! See http://meuleu.homeunix.org Liste de diffusion modem ALCATEL SpeedTouch USB Pour se désinscrire : mailto:[EMAIL PROTECTED]?subject=unsubscribe
[speedtouch] Re: FreeBSD problems + some fixes.
On Wed, 3 Jul 2002, David Hedley wrote: I have tested the watchdog patch and the one from Duncan Sands. Neither make any difference to my connection problems - neither better nor worse. Interestingly however, on my system the watchdog timer never seems to be tripped so I need to look more into that but I haven't had time. 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
