RFC 1662 (HDLC-Like Framing) vs. Microsoft PPP Framing?
Stephen (Steve) L. Egbert
Using MS Direct-Cable-Connection (DCC) between two Win95 platform, I'm
getting the following framing codes on the first packet (after the
non-PPP-standard "CLIENT"/"CLIENTSERVER" string exchange) with a 0x7e
(flag/framing sequence) embedded one or two bytes after data
transmission:
7e ff 7e 7d 23 <supposed xlated to be all-stations ff 03>
Any help? This occurs with hardware control disabled then seen again
with XON/XOFF.
DCC seems able to ignore this extra 7e whereas RFC 1662 (HDLC-like
Framing) Section 4.3 specifically stated to drop the frame silently if:
"Frames which are too short (less than 4 octets when
using the 16-bit FCS) ... are silently discarded, and
not counted as a FCS error."
Because of the problematic characteristic above, I've not been able to
compute a successful FCS. Next question would be:
Are DCC FCS-16 used by default during LCP negotiation stage?
Or silently ignored throughout the connections?
Steve
--
Stephen (Steve) L. Egbert Work: (214) 340-3300
ascom Timeplex Fax: (214) 341-3654
Dallas, Texas 75243-7095 Net: egbert...@timeplex.com
"Try moving off NT easily. You can move from Solaris to HP/UX
to AIX or DEC easily-- relative to moving off of NT, which is
like a Roach Motel. Once you check in, you never check out.
-Scott McNealy, Sun Microsystems, Inc.
James Carlson
In article <32D52D90...@ra.timeplex.com>, "Stephen (Steve) L. Egbert" <egb...@ra.timeplex.com> writes:
|> Using MS Direct-Cable-Connection (DCC) between two Win95 platform, I'm
|> getting the following framing codes on the first packet (after the
|> non-PPP-standard "CLIENT"/"CLIENTSERVER" string exchange) with a 0x7e
|> (flag/framing sequence) embedded one or two bytes after data
|> transmission:
|>
|> 7e ff 7e 7d 23 <supposed xlated to be all-stations ff 03>
|>
|> Any help? This occurs with hardware control disabled then seen again
|> with XON/XOFF.
If that's what they're sending, then they're horribly broken.
|> DCC seems able to ignore this extra 7e whereas RFC 1662 (HDLC-like
|> Framing) Section 4.3 specifically stated to drop the frame silently if:
|>
|> "Frames which are too short (less than 4 octets when
|> using the 16-bit FCS) ... are silently discarded, and
|> not counted as a FCS error."
Yep. That first fragment -- 7E FF -- is just discarded silently by all
RFC-compliant implementations.
The "real" PPP frame is thus starting with "03 ..." which is not valid.
|> Because of the problematic characteristic above, I've not been able to
|> compute a successful FCS. Next question would be:
|>
|> Are DCC FCS-16 used by default during LCP negotiation stage?
FCS-16 is the default for async serial connections, and, yes, must be
used during initial LCP exchange.
|> Or silently ignored throughout the connections?
Hmm.
--
James Carlson <car...@xylogics.com> Tel: +1 617 272 8140
Annex Interface Development / Xylogics, Inc. +1 800 225 3317
53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618