From: Ben Greear <greearb@candelatech.com>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Question on HDLC and raw access to T1/E1 serial streams.
Date: Sat, 30 Sep 2006 15:02:27 -0700 [thread overview]
Message-ID: <451EE973.10907@candelatech.com> (raw)
In-Reply-To: <m3mz8hntqu.fsf@defiant.localdomain>
Krzysztof Halasa wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>
>> I am looking for a way to bridge a T1/E1 network by reading a raw
>> bitstream from one T1 interface and writing it out to the other. The
>> application is adding delay and/or bit corruptions for impairment
>> testing.
>>
>> I have been using Sangoma's drivers and NICs, but I'm having no luck
>> getting their latest stuff to work so I was hoping to use in-kernel
>> drivers (even if that means writing or hiring someone to write new ones.)
>>
>> Is there currently a way to read/write the raw bitstream for a full T1
>> or E1 or a subset of channels?
>>
>
> Well, my generic HDLC works with HDLC framing only, T1/E1 is
> a layer lower than that... I think Cyclades have (had?) a version
> of PC300 card with T1/E1 interface. It at least doesn't require
> any "binary blobs", though I think the driver would need some work.
>
> Which line interface do you need? G.703?
> Do you need to bridge multiple streams (not slots) over one
> interface (internal (de)multiplexer - I mean "more than one
> subset of channels")?
>
For protocols running HDLC as transport, I can just bridge HDLC frames.
I would want
to be able to select the channel(s) for the HDLC frames.
For bridging something like voice, I think if I could break out an
individual channel into
a bit-stream interface, I could just read bits off on one T1 channel and
write to the other.
Preferably, I could also bond multiple channels (including an entire T1
or E1) and bridge
it as raw bits too.
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.
* Configure channels 1-5 as a bitstream and bridge that to channels 1-5
of a second T1. (random proprietary bit-streaming protocol,
would probably bridge HDLC just fine, but handling
HDLC as frames would be more efficient I think.)
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)
* Configure entire T1 as HDLC transport, bridge HDLC frames from one T1
to the other.
Does that make sense?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2006-09-30 22:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-30 1:24 Question on HDLC and raw access to T1/E1 serial streams Ben Greear
2006-09-30 17:34 ` Krzysztof Halasa
2006-09-30 22:02 ` Ben Greear [this message]
2006-10-01 11:54 ` Krzysztof Halasa
2006-10-01 18:41 ` Ben Greear
2006-10-01 20:46 ` Alan Cox
2006-10-04 4:27 ` Ben Greear
2006-10-04 14:20 ` Lennart Sorensen
2006-10-04 18:03 ` Ben Greear
2006-10-01 22:09 ` Krzysztof Halasa
2006-10-02 16:29 ` Ben Greear
2006-10-03 16:08 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=451EE973.10907@candelatech.com \
--to=greearb@candelatech.com \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.