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 mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
