linux-kernel - Re: Question on HDLC and raw access to T1/E1 serial streams.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m3hcyo2qvs.fsf@defiant.localdomain>
Date:	Sun, 01 Oct 2006 13:54:15 +0200
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Ben Greear <greearb@...delatech.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Question on HDLC and raw access to T1/E1 serial streams.

Ben Greear <greearb@...delatech.com> writes:

> I think if I could support these scenarios below, I would have
> everything I need:
>
> *  Configure T1 as unchannelized bitstream, bridge entire thing to
> second T1.

I think it should be easy with such card, though I think the drivers
can't currently do that.

> *  Configure channels 1-5 as a bitstream and bridge that to channels
> 1-5
> of a second T1.  (random proprietary bit-streaming protocol,

I think the hardware would permit that. Probably needs additional
driver support and I'm not sure about timeslot synchronization (for
HDLC, sync doesn't matter).

>                     would probably bridge HDLC just fine, but handling
> HDLC as frames would be more efficient I think.)

Not sure, maybe yes (less data to bridge due to bit stuffing, flags etc.),
maybe not (variable length of HDLC frame).

>    channels 6-10 configured as an HDLC interface, bridged as HDLC
> frames to channels 6-10 of a second T1. (PPP & other protocols over
> HDLC)
>    channels 10-24 each configured as a separate bit-stream, bridged to
> channels 10-24 on the second T1. (Voice)

I think the above could be a problem - I think common T1/E1 cards
can do only one stream at once.

I wonder if it can be done in software - the hardware framer would
have to pass all data transparently, and it would be demultiplexed,
processed and then multiplexed by the driver. Quite complicated,
but I think at 2 Mbps it wouldn't be a CPU performance problem.

> *  Configure entire T1 as HDLC transport, bridge HDLC frames from one
> T1 to the other.

Easy even with existing drivers I think (no bridge support but it's
trivial).
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/