From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: From: Gareth Bradley To: bluez-users@lists.sourceforge.net Subject: Re: [Bluez-users] SCO syncronization taking down USB dongle In-Reply-To: <1139992509.26072.16.camel@localhost> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11850_16745953.1140046857914" References: <1139992509.26072.16.camel@localhost> Sender: bluez-users-admin@lists.sourceforge.net Errors-To: bluez-users-admin@lists.sourceforge.net Reply-To: bluez-users@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ users List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 15 Feb 2006 11:40:57 -1200 ------=_Part_11850_16745953.1140046857914 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thank you for your reply Marcel. the dongle gets disconnected from the USB bus. What kind of dongle is > this? Maybe you need to get yourself a better one, because a disconnect > from the USB is nothing we can really work around. I am unsure of the dongle's actual manufacturer, as it's just a DSE (our Radio Shack equivilant) rebrand. I have since tried it with a Stollman dongle, and am able to get the same result (crash). I am able to get the USB crash with a test program, pasted below. The 'rlen -=3D 1;' line is added to crash it. I am currently unable to test if this w= ill also crash on other platforms, such as on a PC or PDA. Should this be able to take down the dongle? The actual project runs with the number of bytes written to the headset being regulated by the number read from the headset (though the sound is from an external source, not straight back into the headset, like in the example). Is this the correct way to regulate SCO data? while(1){ FD_ZERO(&rfds); FD_SET(serial_fd, &rfds); FD_SET(sd, &rfds); timeout.tv_sec =3D 0; timeout.tv_usec =3D 10000; if((sel =3D select(maxfd + 1, &rfds, NULL, NULL, &timeout)) > 0= ) { if(FD_ISSET(serial_fd, &rfds)){ memset(soundbuf, 0, sizeof(soundbuf)); rlen =3D read(serial_fd, soundbuf, sizeof(soundbuf)); if(rlen > 0){ wlen =3D write(serial_fd, "\r\nOK\r\n", 4); } } if (FD_ISSET(sd, &rfds)) { memset(soundbuf, 0, sizeof(soundbuf)); rlen =3D read(sd, soundbuf, sizeof(soundbuf)); rlen -=3D 1; // This line is able to enduce the crash wlen =3D 0; p =3D soundbuf; while(rlen > sco_mtu){ wlen +=3D write(sd, p, sco_mtu); rlen -=3D sco_mtu; p +=3D sco_mtu; } wlen +=3D write(sd, p, rlen); } } } > I notice that flow (and error) control appear on the Todo list, but is > > there some way to guard against the whole dongle being taken down? > > It only protects the host stack and not the dongle. The flow control > towards the HCI of the dongle is always used. Thanks again for your input. gjb. ------=_Part_11850_16745953.1140046857914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Thank you for your reply Marcel.

the dongle g= ets disconnected from the USB bus. What kind of dongle is
this? Maybe yo= u need to get yourself a better one, because a disconnect
from the USB is nothing we can really work around.
I am unsure of the dongle's actual manufacturer, as it's just a DSE (our Radio Shack equivilant) rebrand. I have since tried it with a Stollman dongle, and am able to get the same result (crash).

I am able to get the USB crash with a test program, pasted below. The 'rlen -=3D 1;' line is added to crash it. I am currently unable to test if this will also crash on other platforms, such as on a PC or PDA. Should this be able to take down the dongle?

The actual project runs with the number of bytes written to the headset being regulated by the number read from the headset (though the sound is from an external source, not straight back into the headset, like in the example). Is this the correct way to regulate SCO data?

        while(1){
            FD_ZERO(&rfds)= ;
            FD_SET(serial_fd, = &rfds);
            FD_SET(sd, &rf= ds);
   
            timeout.tv_sec =3D= 0;
            timeout.tv_usec = =3D 10000;
   
            if((sel =3D select(maxfd + 1, &rfds, NULL, NULL, &timeout)) > 0) {
               = if(FD_ISSET(serial_fd, &rfds)){
                    memset(soundbuf, 0, sizeof(soundbuf));
                    rlen =3D read(serial_fd, soundbuf, sizeof(soundbuf));
               =     if(rlen > 0){
                        wlen =3D write(serial_fd, "\r\nOK\r\n", 4);
               =     }
               = }

               = if (FD_ISSET(sd, &rfds)) {
                    memset(soundbuf, 0, sizeof(soundbuf));
                    rlen =3D read(sd, soundbuf, sizeof(soundbuf));

                    rlen -=3D 1; // This line is able to enduce the crash
               =     wlen =3D 0;
               =     p =3D soundbuf;
               =     while(rlen > sco_mtu){
                        wlen +=3D write(sd, p, sco_mtu);
                        rlen -=3D sco_mtu;
               =         p +=3D sco_mtu;
               =       }
               = wlen +=3D write(sd, p, rlen);

               = }
            }
        }

> I = notice that flow (and error) control appear on the Todo list, but is
>= ; there some way to guard against the whole dongle being taken down?

It only protects the host stack and not the dongle. The flow contro= l
towards the HCI of the dongle is always used. 

Thanks again for your input.

gjb.
------=_Part_11850_16745953.1140046857914-- ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users