Re: [HDLC] Purpose of this Driver?

Re: [HDLC] Purpose of this Driver?

[Krzysztof Halasa]

Telford002@aol.com writes:

> I would recommend a generalized WAN interface that is capable of
> being configured for SDLC Loop (primary & secondary), all variants
> of bisync and transparent modes.  I have clients that do all of these,
> including a very bizarre 13 bit bisync.  And practically every
> variation is used either to carry IP or to communicate with
> a proprietary legacy protocol application.

There is no problem with that. However, things in Linux get implemented
usually because users require them. For now, users want PPP, Frame
Relay, Cisco HDLC.

> > Plus there are different CRCs or no CRC (FCS) at all.
> > In fact, we're using "idle flags" version only (?).
> 
> Why?  It would be trivial to add Mark Idle support.

Of course. But nobody just wanted it.

> Is there a functional specification somewhere that outlines
> the goals of the project?  I have only just started to follow
> this discussion because I included a synchronous HDLC
> flag framing and bit inserting-deleting character driver
> as well as synchronous TTY terminals in the SAB8253X
> ASLX driver that I am in the process of releasing.

No, there is no specification. You can get the idea by browsing hdlc*.c
and include/linux/hdlc.h file (using a modern kernel + my hdlc patch).

> If FR and PPP are to be supported, are LAP, LAPB, LAPD
> to be supported?  How about X.25 Packet Layer, CCITT
> 1976, 1980, 1984, 1988 and BX.25 variants.  How about
> PADs and V.120?
> 
> Obviously, it could take man decades to implement all
> this stuff completely.  But the presence of hooks for
> other people to add such support in later would be great.

The kernel source is open, anyone can add the support.
No special hooks seem necessary. For now, it can do FR, PPP (via
syncppp.c), Cisco, and X.25 is done using Linux X.25 + LAPB stack.

> I would recommend that a generic WAN interface be able
> to interface to the Linux network layer and the TTY
> driver and include some sort of getmsg/putmsg-like
> application interface.

It seems unrelated. Of course the HDLC code interfaces with the network
code. I'd stay away from tty as sync serial devices are rarely used for
TTY-alike communications, and no tty drivers exist for most of such cards.
Obviously, particular driver can support tty mode if needed, or new
"protocol" can be implemented which does exactly that.
-- 
Krzysztof Halasa
Network Administrator

Re: [HDLC] Purpose of this Driver?

[Krzysztof Halasa]

Telford002@aol.com writes:

> HDLC is somewhat ambiguous.  CCITT/ITU documents use HDLC
> to refer to a whole class of protocols.  By raw HDLC, I believe is
> meant a specific BOP (Bit-Oriented Protocl) where flags encapsulate
> frames and the transmitter performs bit insertion and the 
> receiver performs bit deletion.  Even if the usual 0x7e flags
> are used with the standard bit insertion/deletion algorithm, there
> are still two variants, one with flag idles and the other with
> mark idles.

Plus there are different CRCs or no CRC (FCS) at all.
In fact, we're using "idle flags" version only (?).

> Is there a document that attempts to specificy the type of
> WAN interface that is a goal?  In truth, if the intent is the
> specification of a generic WAN interface, I would recommend
> aiming for more generality than basic flag-framing and bit-insertion
> bit-deletion BOP.

Not sure what do you mean - we don't aim at raw HDLC only. Raw HDLC
is included for completness, as well as things like FR or PPP are.

If you think of different encapsulation, it can be added of course.
-- 
Krzysztof Halasa
Network Administrator