Of all the gin joints in all the towns in all the world, Chris Frey had to walk into mine and say:
> On Fri, Jan 16, 2009 at 04:06:34PM -0800, Bill Paul wrote: > > > This is a good idea. I think it should be possible to add a pthread > > > condition on the write, without too much difficulty. Are you able to > > > compile and test the latest CVS/git sources? I'll see if I can whip up > > > a patch tonight. > > > > I'll see if I can give it a try when I get home from work later. > > Ok, I've updated CVS/git with code that adds a '-c' option to pppob. > This turns on handshaking code that prevents writing to USB until it > sees the handshake special packet, or until 1 second passes, whichever > is sooner. This is experimental only, and if it works, great, but if > it doesn't, it will introduce a 1 second latency to a good number of > outgoing packets. Hopefully this latency is enough to determine whether > this theory is sound or not. > > Please let me know if it helps at all for you. I just tried it, but unfortunately I was still able to get the Blackberry to crash under heavy load, even when using the -c option. I actually made a few attempts last night to implement the same change myself, and I ended up with something similar to wha you did, but that didn't seem to fix it either. I also realized that my idea of using select() is a bad one: the ugen(4) generic USB driver in FreeBSD does not implement select() (trying to select on a ugen bulk descriptor always indicates there's an event pending). This is due to the fact that it's semantically a little difficult to implement select on a bulk pipe, at least the way the ugen(4) driver is written. I captured a pppob log of this latest crash. You can see it at: http://www.freebsd.org/~wpaul/bb Look in the bbcrash.txt file. (The file ppp.conf is the ppp(8) configuration that I'm using.) Since I'm on T-Mobile, I'm using the tmobileus chat script included with the distribution to enable tethering. Note that I am still always seeing the special packets after bulk writes. My device does not require a password, so I don't know if the "special initialization" that was mentioned in another e-mail has any meaning here. When the crash happens, there are two reads from the device, followed by a write. Then there is another partial read, and the device disconnects due to reset. There doesn't seem to be a "special packet" returned by the device after the final write before the crash. I'm not sure what this means. For me at least, the crash only seems to occur at peak inbound transfer speeds. This actually makes it a little tough to test, since the network speed seems to be limited by the wireless carrier's network availability. A lot of the time, I'm only getting about 13KB/sec, and at that rate, I never seem to get a crash. It's only once the speed increases to ~26KB/sec that the device gets angry. It seems like I have to wait a bit for a break in network usage before I can approach that speed though. (I had an easier time doing it later in the evening.) I don't know what the theoretical limit is for EDGE. I've experimented a bit by specifying a lower MRU too, but I was still able to reproduce the problem. I have not tried a value less that 512 bytes though. It was mentioned previously that this problem does not happen with Windows Vista. Unfortunately, I don't have a Windows system that I can test with. It would be interesting to see though just what MTU the Windows software uses, and whether or not the "special packets" show up with Windows as well. [...] > > The workaround I used, by the way, was to bind pppob to a pseudo-terminal > > by starting it with a ptyexec perl script that I discovered here: > > > > http://www.mail-archive.com/gnh...@zk3.dec.com/msg05685.html > > > > It's a bit clumsy, but it works. > > Neat. Would you be willing to write up some documentation on this for > other FreeBSD users? The entire Barry documentation is in HTML format > in the source tree, under doc/www/ and I'd be happy to accept patches > to it. I'd suggest adding a section to the end of the modem.php page, > if you have the time. If not, please let me know so I can add it to > my todo list. :-) Well, there's a couple of gotchas that make it a little tricky to create a fully automated solution. The ppp.conf file mentioned above helps. But ppp(8) has one annoying glitch in it that I haven't resolved yet. One of the AT commands you have to issue is: AT+CGDCONT=1,"IP","wap.voicestream.com" Note the double quotes. The ppp(8) utility does not rely on the external chat(8) program like pppd(8) does: it has its on built-in chat script handler, and you can specify the chat script directly in the ppp.conf file. But the script parser seems a bit brain damaged, because I can't for the life of me figure out how to force a literal double quote character down its throat. (I've tried escaping it all sorts of different ways, and it always seems to strip it out.) Because of that, I have to enter the AT commands manually. Usually I do: [...] # ptyexec pppob PID:13011 MASTER: /dev/ptyp? SLAVE: /dev/ttyp? # ppp ppp ON hostname> set device /dev/ttyp? ppp ON hostname> term OK AT+CGDCONT=1,"IP","wap.voicestream.com" OK ATDT*99# CONNECT ~p [...] The ~p causes ppp(8) to switch back out of terminal mode and begin negotiating with the Blackberry, and it brings up the link on its own from there. Like I said, it's a little clumsy, but it works. > I'm happy that Barry seems to work otherwise... under OpenBSD, I needed > to disable the uberry kernel module. (That note is on the dependencies.php > page). I saw that. There isn't a ubarry driver on FreeBSD. However, there is a similar problem. FreeBSD has a umass(8) driver for disk type devices (including USB memory sticks) along with the generic ugen(8) driver. You need to use ugen(8) with the BlackBerry (that's what libusb is built on in FreeBSD). The GENERIC kernel that comes with FreeBSD has USB support and the umass(8) driver compiled in, and when you plug the BlackBerry in, the umass(8) driver will claim it first (ugen(8) is set up to be a fallback in case no other more specific driver match is found). This means you need to build a custom kernel with the umass(8) driver removed in order for ugen(8) to attach to the BlackBerry instead. (There's no way to disable the umass module if it's compiled in.) I had already done this anyway. Note that the USB drivers in FreeBSD are loadable, so you can always dynamically load the umass(8) driver if you need it again without having to do a kernel rebuild. -Bill > Thanks, > - Chris -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wp...@windriver.com | Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
