Have confirmed now that the device responds correctly to lsusb when picocom is "hung". Should have added that I saw some XactErrs when I ran picocom on Openwrt since I was able to build the openwrt kernel with DEBUG defined in cdc-acm and in the kernel. I also changed ehci.h to set the XacErr retry limit to 1 and rebuilt the kernel - but that did not fix the hung problem and lack of response. Previous emails from Alan Stern on the XactErrs have indicated the possibility of a hardware/software error in the usb device controller. All I can say is that the same behaviour has been seen in 2 phones - of course it is possible that the mfgr's implementation is faulty and just happens to work against Windows hosts. Once I am successful getting the same debug capability with my ubuntu kernel I will see if the Xacterrs are reported. That might explain why picocom is hung Regards Ashok On Wed, May 30, 2012 at 1:58 PM, Ashok Rao <ashok@xxxxxxxxxxxxxx> wrote: > Oliver: > I've spent the last week hitting away at this and chasing various red > herrings and here is a summary. > > 1. Proved that Phone does work in Bluetooth DUN mode with Ubuntu - > this is not related to my original question but here just as a FYI > > 2. Moved to doing all the testing on Ubuntu 11.04 to remove any > Openwrt idiosyncrasies. However I can't seem to get verbose messages > after rebuilding the ubuntu 2.6.38-15 kernel with CONFIG_USB_DEBUG. I > also had some issues rebuilding the cdc-acm.c after I defined DEBUG > within it. I will try line6_USB_DEBUG later today and see if that > helps. > > 3. Tested a Samsung Windows Mobile (2008 version as opposed to the > satellite phone which has WM 2003) with ubuntu. It worked fine. Did a > wireshark capture and compared to Ubuntu wireshark of the satphone. > In both cases once picocom is started - the host seems to do about 16 > bulk transfers to an IN endpoint (0x84 for the satphone). See frame > 2568 to 2583 in the pastebin link below. Since it is a IN endpoint > there is no response - that seems logical based on my limited > understanding of how USB works. Not sure why picocom would want to > communicate with a wrong endpoint in both phones. > > Then when I type an A, a bulk transfer to the OUT endpoint 0x05 is > made by the host (see last frame in the pastebin). A late version of > Wireshark labels that as a malformed Ethernet packet - but the ubuntu > wireshark which is older does not call that out. And then there is no > more communications after that for the Satphone. For the Samsung > phone - the AT commands work fine and an OK response is received. > Also tried microcom terminal emulation with the satphone and found > that microcom was able to send the whole AT command but there was no > OK response from the satphone. > > ubuntu wireshark : http://pastebin.com/bN3mkrmT > Windows XP: http://pastebin.com/4aTU51FN > > 5. After some fiddling around with the satphone and reconnecting the > phone to the host and starting picocom I found that suddenly the phone > is sending CREG messages (unsolicitated registration status messages) > to the picocom. These messages are coming from the right IN endpoint > 0x84 - but still the same behavior when I try to type an AT command > > 6. One difference between the Samsung and the Satphone is that the > Samsung is using the same endpoint value (2) for bi-directional > communications - with 0x82 as the IN endpoint and 0x2 as the OUT > endpoint. > Not sure why it would make a difference since the device descriptor is > right in both phones and should be interpreted fine by the usbcore and > driver on ubuntu. > > 7. I am speculating that the barrage of packets to the IN endpoint > caused the Satphone to freeze somehow and not accept the packets on > the right OUT endpoint. I have read your earlier response and will > try lsusb in this state and see if it responds. > > ubuntu wireshark : http://pastebin.com/bN3mkrmT > Windows XP: http://pastebin.com/4aTU51FN > > Ashok > > On Fri, May 25, 2012 at 4:55 AM, Oliver Neukum <oliver@xxxxxxxxxx> wrote: >> >> Am Freitag, 25. Mai 2012, 02:13:30 schrieb Ashok Rao: >> > cable is inserted. Then more data is exchanged when I start picocom >> > and it does the tty initialization. However when I type AT and press >> > return I see that the endpoint changes and a EINPROGRESS message. >> >> In what respect does the endpoint change? >> -EINPROGRESS is normal. >> >> > Nothing after that and picocom is hung. I have to actually kill >> > picocom and the terminal and restart. >> >> Does the phone answer to lsusb in that state? >> >> > I will post the wireshark capture soon. >> >> Good. >> >> > I am planning to compare the wireshark capture in linux to the one on >> > Windows XP and see if that gives a clue. >> >> Good idea. >> >> Regards >> Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
