Rick Scott wrote:
On Sat, 2009-01-17 at 03:01 -0500, Chris Frey wrote:
On Fri, Jan 16, 2009 at 06:48:17PM -0500, Rick Scott wrote:
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.
Hmmm.... I don't see a huge difference in our opening sequence, but
maybe I'm blind to it.
It's not huge ... In modem.c rev 1.27, which I just committed, line 299
is the one that makes the difference. The two attachments are done at
debug = 1 using minicom on /dev/bbmodem0. What I typed, in both cases,
is:
at
at+clac
current.txt is my code, as it is in CVS. broken.txt is the same sequence
with line 299 commented out.
Side answer:
There has been 17 revisions since that comment :) revision 1.11 fixed
that. That was my small buffer read causing a device reset problem, that
I mentioned earlier. Setting the MTU smaller just meant that it didn't
happen as often.
I seem to see that you send a command back to the device after receiving
a "special code" packet. Is that unused code for you, now that you're
not seeing those special packets from the device? (line 298, kernel/modem.c)
Side note:
Your CVS commit messages indicate that using a PPP MTU of <= 384 bytes
helped avoid resets. Are you still using that setting?
- Chris
Rick - Thanks for pointing that out - we do send out that packet (with
the m_session_key) if the modem has a password but we never sent it
without one. :-(
Chris - I'm working on some changes for Shannon and I'll add this to
that patch.
-Andy
------------------------------------------------------------------------------
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
