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>