Date: Tue, 25 Feb 2003 00:26:16 -0300 From: Sergio de Souza Prallon <prallon@tmp.com.br> To: Matthew Horoschun <mhoroschun@canprint.com.au> Subject: Re: Disconnection problem and configuration advice Message-ID: <20030225002616.A10465@tmp.com.br> In-Reply-To: <8713CD4E-484A-11D7-A987-000393B3A702@canprint.com.au>; from mhoroschun@canprint.com.au on Tue, Feb 25, 2003 at 09:51:36AM %2B1100 References: <8713CD4E-484A-11D7-A987-000393B3A702@canprint.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 25, 2003 at 09:51:36AM +1100, Matthew Horoschun wrote:
[...]
>
> Just before the link dies, I get the following messages:
>
> Feb 25 06:46:53 zark /kernel: i4b-L1 itjc_dma_rx_intr: RDO (unit=0)
> dma=508 src=428
> Feb 25 06:46:53 zark /kernel: i4b-L1 itjc_dma_rx_intr: RDO (unit=0)
> dma=520 src=428
Sometimes I see these too when the link is dropped. I believe that your
B-channels stopped receiving valid HDLC data at this exact moment.
> Feb 25 06:47:48 zark /kernel: i4b-L2 i4b_rxd_ack: ((N(R)-1)=4) !=
> (UA=5) !!!
And then, a minute later I4B notes that something is possibly wrong with
the D-channel also. The above message states that the SEQ# of the
incoming D-channel packet is wrong. The carrier is one number ahead of
what your machine expects.
> Feb 25 06:48:58 zark /kernel: i4b-L4 i4b_l4_setup_timeout_fix_unit:
> 1046116138: ERROR: idletime[60]+earlyhup[5] > unitlength[60]!
> Feb 25 06:49:07 zark /kernel: i4b-L4 i4b_l4_setup_timeout_fix_unit:
> 1046116147: ERROR: idletime[60]+earlyhup[5] > unitlength[60]!
This is a config error discovered and reported when, I believe, your
system attempted a redial. Set unitlength to the period of time your
telco charges an active connection. Earlyhangup is probably OK, but
you should make idletime-{in,out}going a least a second smaller than
unitlength-earlyhangup. However, I don't believe this is the reason of
your problems.
I think the telco hung your call and failed to notify your machine of
the fact and the reason for doing so. The cause can be a bug or a timeout
limit in the telco system or on your ISP's NAS. It can even be an I4B bug:
an ill-formed D-channel packet could have driven the switch into a state
where a reset condition on the link was called for.
Try to enable debug on the D-channel and on I.430 events. Next time, may
be we can have something more concrete to look at.
[]'s
--
Prallon
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030225002616.A10465>