[Asterisk-Users] PRI HDLC Abort (6) Errors

[Jerry]

Most T1 circuits are delivered via HDSL2 these days. Hence the single 
pair.


On Mar 4, 2005, at 5:07 PM, Tom wrote:

> Thanks for the quick reply,
> we didn't reboot we'll try that, and I've been planning on building a 
> new
> kernel, I know the fc kernels have issues... I'll report back after I 
> try these
> two things.
>
> On another note we just did some wire tracing and it might be an issue 
> of
> wiring... We have an adtran card that was installed in our network 
> closet that
> has a connection back to the NIU in another suite.  There is only 1 
> pair utp
> going from that adtran card back to the NIU.  Anyone have experience 
> with that?
>  We just spoke to our provider and they said there should be 2 pair, 
> but they
> also said, if there is really only 1 pair, there's no way we'd be able 
> to make
> calls or keep the connection up... We didn't install the wiring, it 
> was done by
> the ILEC here, the CLEC who is providing the service said they would 
> send
> someone out Monday... Anyway, can you run a PRI over just 1 pair with 
> muxing or
> something?
> Thanks,
>
> Tom
>
> Quoting Steven Critchfield <critch at basesys.com>:
>
>> On Fri, 2005-03-04 at 15:27 -0700, Tom wrote:
>>> Hello,
>>> I have searched and searched, and come up with nothing.  I am running
>> Asterisk
>>> with a wcte110p configured for t1.  Our PRI is staying up, and we 
>>> can make
>>> calls however our service provider's logs are flooding with errors 
>>> and we
>> are
>>> getting lots of HDLC Abort (6) on Primary D-Channel Errors.
>>>
>>> Our provider says it looks like our box is trying to be the master 
>>> timer on
>> the
>>> circuit (which is not correct they are providing the timing) we have 
>>> tried
>> both
>>> span=1,1,0,esf,b8zs and span=1,0,0,esf,b8zs in zaptel.conf both 
>>> produce the
>>> same problems.  The problem is not in "Asterisk" per se as the 
>>> errors start
>>> happening as soon as I modprobe the driver and run ztcfg.  As soon 
>>> as the
>>> circuit comes up the errors start on the provider's end.
>>
>> Did you make sure to power cycle afterwords? Sometimes the zap cards
>> don't change critical settings like timing once configured.
>>
>>
>>> We are running CVS Asterisk/zaptel/libpri from March 2nd 2005 on 
>>> Fedora
>> Core 3
>>> fully patched as of last night, I was thinking the problem was with 
>>> the 2.6
>>> kernel getting preempted and therefore the driver not being able to 
>>> do its
>>> timings right, however fc3's kernels have preemption disabled by 
>>> default.
>> Does
>>> Digium hardware really need/expect a real time OS to run properly?
>>> Like I said previously I think the problem is in the driver itself 
>>> not in
>>> asterisk.  Any help would be appreciated, and I can code a bit in c 
>>> so if
>>> someone can point me in the right direction I might be able to fix it
>> myself...
>>
>> You probably want to dump the FC kernel like a bad habit. Get a plain
>> vanilla kernel and see if that fixes your problems.
>> --
>> Steven Critchfield <critch at basesys.com>
>>
>> _______________________________________________
>> Asterisk-Users mailing list
>> Asterisk-Users at lists.digium.com
>> http://lists.digium.com/mailman/listinfo/asterisk-users
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
>