Re: [Barry-devel] Problem with fc10/8120/tmobileus...
On Thu, Jan 15, 2009 at 5:17 PM, Chris Frey cdf...@foursquare.net wrote: On Thu, Jan 15, 2009 at 06:57:01PM -0500, Rick Scott wrote: I tried to build on a mostly virgin FC 10 system today. The lib and tools seemed to build okay, the gui wouldn't configure because of missing gtkmm packages. My effort to yum something suitable for that failed. I believe 'yum search gtkmm' should have found something for you. gtkmm24 should do the trick. You'll need libglademm20 and friends too, but I'd be surprised if they weren't available. Even libtar is listed on Fedora's package page. Remember you have to install the -devel versions of these packages. -edge -- 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
Re: [Barry-devel] Problem with fc10/8120/tmobileus...
On Fri, 2009-01-16 at 04:26 -0700, Brian Edginton wrote: On Thu, Jan 15, 2009 at 5:17 PM, Chris Frey cdf...@foursquare.net wrote: On Thu, Jan 15, 2009 at 06:57:01PM -0500, Rick Scott wrote: I tried to build on a mostly virgin FC 10 system today. The lib and tools seemed to build okay, the gui wouldn't configure because of missing gtkmm packages. My effort to yum something suitable for that failed. I believe 'yum search gtkmm' should have found something for you. gtkmm24 should do the trick. You'll need libglademm20 and friends too, but I'd be surprised if they weren't available. Even libtar is listed on Fedora's package page. Remember you have to install the -devel versions of these packages. Better than that Too many m's :( Those, and libtar, and things seem to work okay. -edge -- 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 -- 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
Re: [Barry-devel] Blackberries rebooting during tethering (was Re: Using pppob with a brazilian provider (TIM))
Hi Bill, Thanks for your bug report! On Fri, Jan 16, 2009 at 10:28:58AM -0800, Bill Paul wrote: I don't know for sure what's causing the problem yet, but I have a suspicion. Looking at the log file generated by pppob, there seems to be a pattern to the data transfer. In particular, whenever pppob does a USB bulk write, it's typically followed by a USB bulk read of an IPModem special packet. The DataReadThread() method in m_ipmodem.cc does not do any special processing of these messages and just discards them, but I think this might be the wrong behavior. It looks an awful lot like these messages are write completion acknowledgements; if so, I think the right thing to do is wait for the acknowledgement after each write before proceeding to the next write. 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. It should be possible to avoid the use of threads here and obtain the desired behavior by making use of select() in pppob to monitor both the stdin file descriptor and the USB bulk read descriptor simultaneously. Unfortunately, the current design of both pppob and the m_ipmodem.cc module make this a little hard to do. I think I can rework them a little to make it possible to at least test this approach and modify the IpModem::Write() method to wait for acknowledgement, but it may take me a few days. When I started writing the modem support for Barry, I wanted to do it the same way, using select(). Unfortunately, I was not able to do this easily. I wanted to keep using libusb, since this gives me easier cross-platform compatibility. Indeed, you probably wouldn't be using Barry on FreeBSD at all without libusb. The current stable version of libusb does not make it easy to use select() on its read operations, nor does it provide asynchronous calls. Even earlier in Barry's development I started using the devel branch of libusb in order to use those asynchronous calls, but that was years ago, and the old stable libusb is still the main one, so I dropped that in favour of a stable libusb that is available everywhere. So that left threads, and that's the API we have today. Oh, a few notes on getting pppob to work with FreeBSD: - Building barry fails unless you have GCC 4. This is because the router.cc module seems to depend on something called C++ Technical Report 1 library extensions, which are not present in GCC 3. (Current versions of FreeBSD include GCC 4 in the base install, but FreeBSD 6.0 comes with GCC 3.4.4. This means I had to build a newer GCC on my laptop before I could compile barry.) Is it really necessary to make the code dependent on this extension? The tr1 headers are only used for the shared_ptr template. So technically, there are 3 ways to proceed: 1) copy the shared_ptr header in Barry 2) use tr1 3) make the Boost libraries a mandatory dependency The drawback of #3 is that Boost is a pretty large dependency for just one header, even though btool uses it optionally for the seriallization support. The drawback of #1 is that it causes duplication and potential conflicts with other shared_ptr implementations without special care. I really don't like copying code that should be in external libraries, especially when it is in two external libraries already. The drawback of #2 is that it requires a newer GCC, but even Debian stable had it, so I figured it was a safe bet. The primary advantage of #2 is that it is part of the C++ standard process, and so is likely the most portable way to advance. And I'm very much in favour of progressing to the latest C++ standard features as soon as possible, for productivity reasons. I realize there's some inconvenience, but in the greater scheme of things, I think keeping up with C++ standards is important enough to bear a little upgrade pain. - The version of pppd included with FreeBSD is 2.3 patch level 5. Linux seems to use pppd 2.4. The main problem with this is that the pty directive doesn't exist in pppd 2.3pl5, which makes it hard to use pppob with it. I found a workaround for this, but I still had problems (pppd would not negotiate a link). I finally gave up on pppd and used the user-space ppp(8) utility in FreeBSD, and had better luck with it. (The one trick to it seems to be that you have to disable VJ header compression.) I'm glad there was a workaround. Is there any reason why FreeBSD is still using 2.3? If my web search was correct, it appears that pppd 2.4 was released in 2000. - Chris -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Barry-devel
Re: [Barry-devel] Blackberries rebooting during tethering (was Re:Using pppob with a brazilian provider (TIM))
I seem to have run afoul of the same problem. I just got a Blackberry Curve 8320 from T-Mobile (OS version 4.5.0.81), and I set up tethering with my laptop running FreeBSD. In my case, the crash occurs during periods of heavy network load. One of the first things I did after I set it up was to try to measure the data transfer speed by downloading a file using fetch(1) (similar to wget(1) in linux). The transfer would run for a while, then the Blackberry would reset. I've observed two failure modes: - The LED turns red, the screen turns white, a spinning hourglass appears and remains on screen for up to a minute, then the T-Mobile logo appears for a few seconds, and finally the menu appears. - The LED turns red, the screen turns white for about 10 seconds, then the menu reappears. As soon as the main menu returns, the EDGE link appears good, but then it drops (red X through the antenna icon) and renegotiates. In both cases, the Curve disconnects from the USB bus. This coincides with an I/O error during usb_bulk_read(). I ran pppob with debugging turned on, and the log file shows what looks like a partial read: normally it's reading full sized frames of about 1492 bytes (which corresponds to the TCP segments arriving) but the last read before the crash only gets about 1088 bytes. Hi Bill and Chris, This may be useless information, but I'll throw it in just in case. I have Sprint and I've observed this same failure when watching Sprint TV. It seems to occur after a certain period of time for me, usually after about 30 minutes or so, but I'll get the red LED you mention, the screen goes black, the Sprint logo comes up, then the hour glass on a white screen, it verifies my security software and then I can use my menu. A Sprint tech at one of the stores told me this was due to a memory leak, but perhaps heavy network load could cause it as well. Just something else to consider. Chris S -- 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
Re: [Barry-devel] Blackberries rebooting during tethering (was Re: Using pppob with a brazilian provider (TIM))
On Fri, 2009-01-16 at 10:28 -0800, Bill Paul wrote: On Wed, 2009-01-07 at 09:30 -0200, Pablo Borges wrote: The only bummer is, after a few minutes surfing teh internets my blackberry reboots (O_O). I guess it has something to do with the firmware that I need to upgrade. :/ Someone reported something similar to me on my blog the other day: Barry does show great potential, but has a show-stopping bug for me. See my report on SF: Bug # 2480631… http://www.happyassassin.net/2009/01/04/activity-and-blackberry-tethering-article/ and ISTR it's been reported to the list, too. This seems to be a general bug...and at least for your case and the blog case, the offending model is a Curve... The bug report referred to in the comment is: http://sourceforge.net/tracker/index.php?func=detailaid=2480631group_id=153722atid=788904 -- adamw http://www.happyassassin.net I seem to have run afoul of the same problem. I just got a Blackberry Curve 8320 from T-Mobile (OS version 4.5.0.81), and I set up tethering with my laptop running FreeBSD. In my case, the crash occurs during periods of heavy network load. One of the first things I did after I set it up was to try to measure the data transfer speed by downloading a file using fetch(1) (similar to wget(1) in linux). The transfer would run for a while, then the Blackberry would reset. I've observed two failure modes: - The LED turns red, the screen turns white, a spinning hourglass appears and remains on screen for up to a minute, then the T-Mobile logo appears for a few seconds, and finally the menu appears. - The LED turns red, the screen turns white for about 10 seconds, then the menu reappears. As soon as the main menu returns, the EDGE link appears good, but then it drops (red X through the antenna icon) and renegotiates. In both cases, the Curve disconnects from the USB bus. This coincides with an I/O error during usb_bulk_read(). I ran pppob with debugging turned on, and the log file shows what looks like a partial read: normally it's reading full sized frames of about 1492 bytes (which corresponds to the TCP segments arriving) but the last read before the crash only gets about 1088 bytes. Oh, with my EDGE connection via T-Mobile, the link speed seems to max out at about 26KB/sec. (That's kilobytes per second.) I do device driver development for a living, and to me, a failure under load such as this typically indicates a race condition. Races are somewhat less likely to occur in user mode code, but I suppose they're still possible. I don't know for sure what's causing the problem yet, but I have a suspicion. Looking at the log file generated by pppob, there seems to be a pattern to the data transfer. In particular, whenever pppob does a USB bulk write, it's typically followed by a USB bulk read of an IPModem special packet. The DataReadThread() method in m_ipmodem.cc does not do any special processing of these messages and just discards them, but I think this might be the wrong behavior. It looks an awful lot like these messages are write completion acknowledgements; if so, I think the right thing to do is wait for the I don't think that is the case. I think it shows incomplete initialization handshaking. I'm pretty sure I got it to stop sending this packet in response to every write by paying closer attention to the init sequence. acknowledgement after each write before proceeding to the next write. That is, instead of just doing a usb_bulk_write() and returning immediately, I think you need to do the bulk write, then issue a bulk read and wait for the acknowledgement to arrive, _then_ return. (And then it's safe to monitor the read pipe for incoming traffic again.) My money says that this mechanism is used to both rate limit the data transfered from the host to the device and to keep host and device synchronized. I looked over the code briefly hoping that I might be able to do a quick experiment to test this theory, but that turned out to be a little trickier than I expected. This is partly because the code is written in C++ (I'm an expert in C, but I only know a little bit about C++), and partly because it uses threads. The m_ipmodem.cc module in particular uses a thread to listen for inbound data from the device. This complicates things a little: I was hoping to avoid having the read and write operations running indepentently of each other (since I want the wait for acknowledgement operation performed after a write not to collide with the normal read operations -- I especially don't want to end up trying to queue two bulk read operations at once). It should be possible to avoid the use of threads here and obtain the desired behavior by making use of select() in pppob to monitor both the stdin file descriptor and the USB bulk read descriptor simultaneously. Unfortunately, the current
Re: [Barry-devel] Blackberries rebooting during tethering (was Re: Using pppob with a brazilian provider (TIM))
Of all the gin joints in all the towns in all the world, Chris Frey had to walk into mine and say: Hi Bill, Thanks for your bug report! On Fri, Jan 16, 2009 at 10:28:58AM -0800, Bill Paul wrote: I don't know for sure what's causing the problem yet, but I have a suspicion. Looking at the log file generated by pppob, there seems to be a pattern to the data transfer. In particular, whenever pppob does a USB bulk write, it's typically followed by a USB bulk read of an IPModem special packet. The DataReadThread() method in m_ipmodem.cc does not do any special processing of these messages and just discards them, but I think this might be the wrong behavior. It looks an awful lot like these messages are write completion acknowledgements; if so, I think the right thing to do is wait for the acknowledgement after each write before proceeding to the next write. 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. [...] When I started writing the modem support for Barry, I wanted to do it the same way, using select(). Unfortunately, I was not able to do this easily. I wanted to keep using libusb, since this gives me easier cross-platform compatibility. Indeed, you probably wouldn't be using Barry on FreeBSD at all without libusb. The current stable version of libusb does not make it easy to use select() on its read operations, nor does it provide asynchronous calls. Even earlier in Barry's development I started using the devel branch of libusb in order to use those asynchronous calls, but that was years ago, and the old stable libusb is still the main one, so I dropped that in favour of a stable libusb that is available everywhere. So that left threads, and that's the API we have today. Yeah, after I sent my e-mail earlier, I grabbed the source to libusb, and I noticed that. It shouldn't be too hard to add an API to libusb to extract the underlying file descriptors, but as you say, that would be a non-standard patch to it. Oh, a few notes on getting pppob to work with FreeBSD: - Building barry fails unless you have GCC 4. This is because the router.cc module seems to depend on something called C++ Technical Report 1 library extensions, which are not present in GCC 3. (Current versions of FreeBSD include GCC 4 in the base install, but FreeBSD 6.0 comes with GCC 3.4.4. This means I had to build a newer GCC on my laptop before I could compile barry.) Is it really necessary to make the code dependent on this extension? The tr1 headers are only used for the shared_ptr template. So technically, there are 3 ways to proceed: [...] *looks up what shared_ptr is supposed to do* Oh, I see. Well, ok then. I realize there's some inconvenience, but in the greater scheme of things, I think keeping up with C++ standards is important enough to bear a little upgrade pain. I'm going to bite my tongue, lest this descend into a C vs. C++ war. :) - The version of pppd included with FreeBSD is 2.3 patch level 5. Linux seems to use pppd 2.4. The main problem with this is that the pty directive doesn't exist in pppd 2.3pl5, which makes it hard to use pppob with it. I found a workaround for this, but I still had problems (pppd would not negotiate a link). I finally gave up on pppd and used the user-space ppp(8) utility in FreeBSD, and had better luck with it. (The one trick to it seems to be that you have to disable VJ header compression.) I'm glad there was a workaround. Is there any reason why FreeBSD is still using 2.3? If my web search was correct, it appears that pppd 2.4 was released in 2000. That's a good question. I think interest in pppd dropped off a lot once the user mode ppp(8) application was introduced. Getting it updated would require some interest from a developer, and nobody seems to want to get tagged with it. Unfortunately, upgrading it from 2.3 to 2.4 is non-trivial: the stock pppd distribution only supports Linux and SunOS by default, and there seem to be enough differences between the two versions that updating FreeBSD's OS-specific sys-bsd.c module would take a bit of work and testing. 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. -Bill - 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.
Re: [Barry-devel] Blackberries rebooting during tethering (was Re: Using pppob with a brazilian provider (TIM))
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. That's a good question. I think interest in pppd dropped off a lot once the user mode ppp(8) application was introduced. Getting it updated would require some interest from a developer, and nobody seems to want to get tagged with it. Unfortunately, upgrading it from 2.3 to 2.4 is non-trivial: the stock pppd distribution only supports Linux and SunOS by default, and there seem to be enough differences between the two versions that updating FreeBSD's OS-specific sys-bsd.c module would take a bit of work and testing. Ahhh, yes... kernel side changes on FreeBSD would be a good enough reason. :-) 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. :-) 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). Thanks, - Chris -- 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
