Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 06 Jun 1998 18:01:26 +0200
From:      Harald Hanche-Olsen <hanche@math.ntnu.no>
To:        freebsd-isdn@FreeBSD.ORG
Subject:   Re: idletime disconnect won't work
Message-ID:  <19980606180126V.hanche@math.ntnu.no>
In-Reply-To: Your message of "Sun, 31 May 1998 15:40:54 %2B0200 (CEST)" <m0yg8M2-00024SC@bert.kts.org>
References:  <m0yg8M2-00024SC@bert.kts.org>

next in thread | previous in thread | raw e-mail | index | archive | help
- hm@kts.org (Hellmuth Michaelis):

| Harald Hanche-Olsen wrote:
| 
| > Apparently, there is some sort of incoming traffic which hinders the
| > idle timer from ever reaching its timeout value.
| > 
| > What can this traffic be?  How can I find out something more about it?
| 
| I have no idea about this since i'm not a ppp expert. Joerg ?
| 
| > Again, how can I find out more about what is happening?
| 
| By debugging at various parts and levels of i4b. Using isdndebug you are
| able to trace many events at all layers of the kernel part;

OK, I finally got around to trying that.  I ran isdndebug -m, then a
ping which caused the machine to go online, killed the ping and waited
for the timeout to happen.  It never did; instead, once every 10
seconds this happens:

Jun  6 17:21:11 thoth /kernel: i4b-L4-i4b_idle_check: 897146471: outgoing-call-st, activity, last_active=897146461, max_idle=30
Jun  6 17:21:11 thoth /kernel: i4b-L2-i4b_rxd_s_frame: rx'd RR, N(R) = 2
Jun  6 17:21:11 thoth /kernel: i4b-L2-F_MF17: FSM function F_MF17 executing
Jun  6 17:21:11 thoth /kernel: i4b-L2-i4b_tx_rr_response: tx RR, unit = 0
Jun  6 17:21:11 thoth /kernel: i4b-L1-ph_data_req: ISAC_TX_ACTIVE set
Jun  6 17:21:11 thoth /kernel: i4b-L2-i4b_T200_stop: unit 0
Jun  6 17:21:11 thoth /kernel: i4b-L2-i4b_next_l2state: FSM S-event [EV_RXRR]: [ST_MULTIFR => ST_MULTIFR]
Jun  6 17:21:11 thoth /kernel: i4b-L4-i4b_idle_check: 897146471: outgoing-call-st, activity, last_active=897146471, max_idle=30

(The idle_check message appears once a second, but its associated
activity time stamp (897146471, 897146471 etc) is only updated when
the other activity takes place.)

This seems to be as much information as I can get without beginning to
add my own debug code.

Can you tell from this what may be going on?  I.e., is it the remote
ISDN router that is chattering away, or may it be the exchange?  Is
there perhaps anything I might do in order for this particular event
not to update the activity timer, without disrupting the entire
timeout mechanism?

Oh, and on a different note -- is there some documentation about ISDN
I might look at to gain some understanding of the protocols involved,
without necessarily reading the entire standards document?

- Harald

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?19980606180126V.hanche>