HDLC was originally a bit-stream protocol. There is no size field, etc.
because bit stuffing insures that the sync pattern does not accidentally
occur. Bit stuffing is a pain, so many protocols (ex. PPP, T.120, etc.)
also have a standard for byte stuffing (basically an escape char/byte
sequence). If byte stuffing is not covered in RFC1662, it will be
covered in one of the referred to documents. The ITU Q.93x
specifications cover all this in agonizing detail...
Good Luck,
-jjf
-----Original Message-----
From: Andreas Wolf [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 05, 2000 6:07 AM
To: Palm Developer Forum
Subject: PPP via direct/serial
Hi,
you might have heard of Mocha W32 PPP (mPPP, http://www.mochasoft.dk ),
a
Windows application that allows you to use the cradle/serial connection
as
a direct PPP line. As I understand it, the Palm settings are
direct/serial
for the connection and PPP for network. If you start a TCP/IP connection
from, say ProxiWeb, the Palm should intitiate a PPP connection, which is
answered by mPPP on the PC side. Any TCP/IP packets are then
forwarded/routed to Internet connection of the PC (LAN, modem etc.)
Unfortunately I have a Macintosh and no such thing as mPPP seems to
exist
for the Mac. So write the software yourself, right? Well, I got stuck
right
in the beginning and have hundreds of questions now :-))))
My setup is: PalmV in its cradle connected to the Mac's serial port
(modem). Baud rate set to 19200. Starting a web-site from Proxiweb. This
invokes all the data link layers (I hope). On the Mac side I currently
just
read the raw hex data-stream from the serial port.
>From all the RFCs that I found on the topic PPP, I "assume" that PPP
over
the serial port conforms to RFC1662 which describes "PPP in HDLC-like
Framing". Perhaps this is the first wrong assumption? If I look at the
data-stream it starts with the sequence:
7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 ....
So I think I see here the FrameFlag (0x7E) followed by an all stations
address field (0xFF). This part is o.k. However, the next octet should
be
the control field, which RFC1662 states should be 0x03. I have 0x7D
there.
The next part should be the PPP encapsulation (RFC1661). 16 Bit for the
protocol field, i.e. 0xC021. Great, that stands for link control
protocol
(LCP). That should be followed by the code field (I would expect a
configure-request code = 1 here), but 0x7D makes no sense in that
context,
neither the following part.
So what's wrong? I have no parity, 8 data bits, 1 stop bit (tried
others)
for the Mac's serial port, but I couldnt find any description for the
Palm
(any hints?). What framing protocol is used for the Palm serial port?
Might
it be a cabling problem? I heard the serial cable connection of the
cradle
is different from a modem cable (no commercial available?). But then I
would expect that the whole connection doesnt work. I really need some
documentation on the data-stream that is produced by the combination
PPP,
direct/serial on the Palm.
Any help is greatly appreciated, Andreas
*************************************************
* *
* Dr. Andreas Wolf *
* Abteilung Biophysik *
* Albrecht-von-Haller-Institut *
* f�r Pflanzenwissenschaften *
* Uni G�ttingen *
* Untere Karsp�le 2 *
* D-37073 G�ttingen *
* *
* http://www.biophysik.uni-goettingen.de *
* *
*************************************************
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
