Hi,
Occasionally for a day our server will through lots of HDLC errors in
the log and the PRI card with go into alarm.
I have done some searching and this seems to mostly caused from
Hardware incompatibilities / IRQ sharing / Faulty card / Telco problem
The card will generally run for weeks
Well how do you test with one of the cheap continuity testers or with
a Fluke or similar?
Also just for the heck of it... I assume in your zapata.conf your lbo
is set to 0 try 1 see if it makes a difference. Most of the time your
CSU/DSU/NIU will autodetect this change. But just try it see what
Good to know they are helping you out. Post the outcome if you can,
specifically if they send you the same model and revision card and if
it resolves your issue. If you can try to make a note of your current
firmware version before you send it off.
On Jan 18, 2008 5:25 PM, Steven Kurylo [EMAIL
I have a suggestion. Have you contacted Digium technical support
for assistance
with resolving this issue?
Excellent suggestion. Make sure you can give them SSH access and
screen so you can see what they are doing. Before that, check
(remake) your T1 cables and if it is punched down
On Wed, 2008-01-16 at 15:52 -0800, Steven wrote:
I'm running Asterisk 1.2.26.1 svn rev 79171 on Trixbox 2.2. libpri
1.2.7 and zaptel 1.2.22.1. The hardware is a HP dl360 single cpu with a
TE220B. The system load is below 0.10.
I moved the server into production, with one PRI, on Friday.
I have a suggestion. Have you contacted Digium technical support
for assistance
with resolving this issue?
Excellent suggestion. Make sure you can give them SSH access and
screen so you can see what they are doing. Before that, check
(remake) your T1 cables and if it is
Andrew Joakimsen wrote:
I'll assume you chose trixbox to make your life easier when it comes to
dealing with others
regarding the PBX.
Pretty much, yes.
What is between the smartjack and your T1 card? What sort and length
of cable? Any splices? Punchdown or patch panels?
About 100
You mention went into production, Did this imply moving of the system
from a testing room into a server-location? Other (longer) cables?
Unplugged the current system and hooked up a new, longer, cable to the
asterisk system. The cable is RJ48 STP, about 100 feet. However we ran
several
I'm running Asterisk 1.2.26.1 svn rev 79171 on Trixbox 2.2. libpri
1.2.7 and zaptel 1.2.22.1. The hardware is a HP dl360 single cpu with a
TE220B. The system load is below 0.10.
I moved the server into production, with one PRI, on Friday. On that
day we handled a couple thousand calls and
Steven wrote:
I'm not sure what to try next, other than calling the telco and asking
them to check their equipment. Does any one have a suggestion before I
do that?
I have a suggestion. Have you contacted Digium technical support for
assistance
with resolving this issue?
--
Russell
On Jan 16, 2008 7:07 PM, Russell Bryant [EMAIL PROTECTED] wrote:
Steven wrote:
I'm not sure what to try next, other than calling the telco and asking
them to check their equipment. Does any one have a suggestion before I
do that?
I have a suggestion. Have you contacted Digium technical
Trixbox 2.2... I assume you are using the latest version. Normally I
will ignore messages from trixbox users because they ask kindergarten
stuff... but you seem to be knowledgeable and I'll assume you chose
trixbox to make your life easier when it comes to dealing with others
regarding the PBX.
I
Yeah, post your relevant portions of zaptel.conf. Usually it's a
timing problem if you have HDLC abort errors.
Matthew Fredrickson
On Nov 6, 2005, at 11:32 PM, kurt turner wrote:
Sounds like a timing issue or interop issue. Get rid of the NFAS (3rd
t1 with all B channels) and make them
Matthew Fredrickson wrote:
Yeah, post your relevant portions of zaptel.conf. Usually it's a timing
problem if you have HDLC abort errors.
Actually, it's usually a motherboard or card problem that causes HDLC
errors. Frequent causes are SATA controllers, IDE controllers, graphics
modes,
The blanket statement that it's a motherbord or card problem is thrown around
far too readily IMO. This is often just another way of saying that I have two
(or more) pieces of hardware that don't play partucilarly nicely together in
their default configuration, but I'm too lazy/busy/scared (I'm
Sounds like a timing issue or interop issue. Get rid of the NFAS (3rd t1 with all B channels) and make them all plain PRIs without D channel sharing.
Jason Walker [EMAIL PROTECTED] wrote:
I have looked through other postings to the user group for HDLC errors, went through what worked for other
I have looked
through other postings to the user group for HDLC errors, went through what
worked for other people, and still can not seem to get past this
issue.
For 3 days, I have
been getting HDLC abort(6) errors in *. Prior to Tuesday, the circuits were
clean...I had maybe 10 HDLC
17 matches
Mail list logo
