All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.