Hi, I've been modifying barry to add support for USB channels in my git branch at git://github.com/tobygray/barry-usbrelay.git
The intention has been to provide an API with similar functionality to the channel API in the BlackBerry desktop manager API. I implemented this as a new mode named RawChannel and have included a tool which connects uses STDIN and STDOUT to send and received data over the RawChannel. This allows Barry to be used to interface with applications running on a BlackBerry which have made use of the net.rim.device.api.system.USBPort API (http://www.blackberry.com/developers/docs/4.0.2api/net/rim/device/api/system/USBPort.html). I appreciate that this is not a small patch, so any comments, suggestions or improvement are more than welcome. When implementing this I noticed a few things which might be of general interest: 1 - BlackBerry OS v4.x connections are unreliable due to interactions with usb_storage driver. This one took me a while to track down, but it manifests such that about 50% of the time when you set up a channel/socket with the BlackBerry that it would always fail after 30 seconds. Looking at the USBmon traces it appears that usb_storage issues a command which it doesn't get a response to. After 30 seconds with no response the usb_storage driver resets the BlackBerry USB device, causing the channel to drop. If I rmmod the usb_storage module then channel connections are reliable and long lasting. BlackBerry OS v5.x devices work fine, regardless of if usb_storage is loaded. I could also get OS v4.x devices to work reliably by using usb_detach_kernel_driver_np. I have USBmon traces available if anyone is interested in working out what mass storage command is timing out. 2 - Data can only be reliably sent on the channel by waiting for a SB_COMMAND_SEQUENCE_HANDSHAKE. The RawChannel code waits for a SB_COMMAND_SEQUENCE_HANDSHAKE after sending a data packet to the BlackBerry before sending another packet. This is necessary as otherwise the BlackBerry appears to ignore the second data packet. I assume this isn't seen as an issue in the other Barry modes due to the send/receive nature of the protocols. 3 - It seems that the SB_COMMAND_SEQUENCE_HANDSHAKE might have a byte identifying the socket. I've not confirmed this by trying to run two modes at once, but the sequence numbers seem to be per socket rather than per device. If this is true then one would hope that there is some way for the SB_COMMAND_SEQUENCE_HANDSHAKE to be associated with the correct socket. However looking at the data in the packet there doesn't appear to be space for a 16 bit socket number. However there does appear to be a byte (SequenceCommand::unknown1) which correspond to the socket number. This might just be coincidence though as there's no obvious way as to how a socket number > 255 would be handled. Regards, Toby ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
