Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2003 09:33:18 +0200
From:      Ari Suutari <ari.suutari@syncrontech.com>
To:        Gary Jennejohn <garyj@jennejohn.org>, G Hasse <gh@raditex.se>
Cc:        freebsd-isdn@FreeBSD.ORG
Subject:   Re: Problem with "no bufferspace"
Message-ID:  <200301220933.18435.ari.suutari@syncrontech.com>
In-Reply-To: <200301212017.h0LKHc94041492@peedub.jennejohn.org>
References:  <200301212017.h0LKHc94041492@peedub.jennejohn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

I tried this on test environment, which tries to open connection
to another box which has been changed so that in never answers
the incoming call.

Here is what happens (on freebsd 4.7-stable which tries to dial)

# ifconfig isp1
isp1: flags=3Da011<UP,POINTOPOINT,LINK1,MULTICAST> mtu 1500
        inet 192.168.99.1 --> 192.168.99.2 netmask 0xffffff00

# ping 192.168.99.2
PING 192.168.99.2 (192.168.99.2): 56 data bytes
^C

On console I now see:
Jan 22 09:17:18 test /kernel: i4b: unit 0, assigned TEI =3D 67 =3D 0x43
Jan 22 09:17:19 test /kernel: i4b_l4_disconnect_ind: cd->dlt is NULL

On isdnd log:
 Jan 22 09:17:18 test isdnd[69]: DBG msg_dialout: dial req from isp, unit=
 1
Jan 22 09:17:18 test isdnd[69]: DBG setup_dialout: entry StMobile ok!
Jan 22 09:17:18 test isdnd[69]: DBG find_by_device_for_dialout: found ent=
ry 1!
Jan 22 09:17:18 test isdnd[69]: DBG FSM event [msg-dialout]: [idle =3D> d=
ialing]
Jan 22 09:17:18 test isdnd[69]: DBG F_DIAL: local dial out request
Jan 22 09:17:18 test isdnd[69]: DBG select_first_dialno: only one no, no =
=3D=20
xxxx
Jan 22 09:17:18 test isdnd[69]: CHD 00001 StMobile rate 0 sec/unit (conf)
Jan 22 09:17:18 test isdnd[69]: DBG sendm_connect_req: ctrl =3D 0, chan =3D=
 -1
Jan 22 09:17:18 test isdnd[69]: DBG decr_free_channels: ctrl 0, now 1 cha=
n=20
free
Jan 22 09:17:18 test isdnd[69]: CHD 00001 StMobile dialing out from yyyy =
to=20
xxxx
Jan 22 09:17:18 test isdnd[69]: DBG msg_l12stat_ind: unit 0, layer 1, sta=
te 1
Jan 22 09:17:18 test isdnd[69]: DBG msg_teiasg_ind: unit 0, tei =3D 67
Jan 22 09:17:18 test isdnd[69]: DBG msg_l12stat_ind: unit 0, layer 2, sta=
te 1
Jan 22 09:17:18 test isdnd[69]: DBG set_channel_busy: controller [0] chan=
nel=20
B1 set to BUSY!
Jan 22 09:17:18 test isdnd[69]: CHD 00001 StMobile outgoing call proceedi=
ng=20
(ctl 0, ch 0)
Jan 22 09:17:19 test isdnd[69]: CHD 00001 StMobile outgoing call disconne=
cted=20
(remote)
Jan 22 09:17:19 test isdnd[69]: CHD 00001 StMobile cause 38: Network out =
of=20
order (Q.850)
Jan 22 09:17:19 test isdnd[69]: DBG set_channel_idle: controller [0] chan=
nel=20
B1 set to IDLE!
Jan 22 09:17:19 test isdnd[69]: DBG incr_free_channels: ctrl 0, now 2 cha=
n=20
free
Jan 22 09:17:19 test isdnd[69]: DBG F_DFL: dial retry fail, dial retries=20
exhausted
Jan 22 09:17:19 test isdnd[69]: DBG dialresponse: sent [temporary failure=
]
Jan 22 09:17:19 test isdnd[69]: DBG FSM (SUSE) event [msg-disc-ind]: [dia=
ling=20
=3D> idle]
Jan 22 09:17:29 test isdnd[69]: DBG msg_l12stat_ind: unit 0, layer 2, sta=
te 0
Jan 22 09:17:39 test isdnd[69]: DBG msg_l12stat_ind: unit 0, layer 1, sta=
te 0

Now, when I look at the isp1 with spppcontrol:
# spppcontrol isp1
isp1:   phase=3Destablish

it is still in 'establish' state.

Now, if I try to ping the remote again, nothing happens, because
the interface is in 'establish' state and it thinks that something
is still going on. The packet is just queued... keep on pinging and:

# ping 192.168.99.2
PING 192.168.99.2 (192.168.99.2): 56 data bytes
ping: sendto: No buffer space available
ping: sendto: No buffer space available

So there is something wrong when isdnd sends dial response:
Jan 22 09:17:19 test isdnd[69]: DBG dialresponse: sent [temporary failure=
]

it must be so that this is not catched by isp device -- it should
go back to 'idle', shoudn't it ?

=09Ari S.

On Tuesday 21 January 2003 22:17, Gary Jennejohn wrote:
> G Hasse writes:
> > On Wed, 15 Jan 2003, Ari Suutari wrote:
> > > > What if i define all interfaces to use a specific isdnchannel
> > > > then it might be signaled "busy"? Have anyone tried this?
> > >
> > > I have boxes with two isp interfaces which both
> > > have isdnchannel set to -1. isdnd seems to be smart enough
> > > to pick a free channel. Still, when dialling has failed
> > > the isp interface is left into 'establish' state and it
> > > never recovers without doing ifconfig down & up.
> >
> > Ok. Then there seems to be a real "bug" here. (If our configuratons
> > are correct). I have many "interfaces" but just two ISDN channels,
> > but this don't seems to be the problem then.
>
> OK, assuming you guys are using 4.7 or -stable, I'd appreciate if you
> could apply this patch and tell the list what (if anything) comes out
> of the new debug printf's when you see the problem. Thanks!
>
> --- driver/i4b_isppp.c.orig=09Tue Jan 21 20:58:56 2003
> +++ driver/i4b_isppp.c=09Tue Jan 21 21:01:34 2003
> @@ -580,6 +580,7 @@
>  =09/* new stuff to check that the active channel is being closed */
>  =09if (cd !=3D sc->sc_cdp)
>  =09{
> +=09=09printf("isp%d, channel%d not active!", unit, cd->channelid);
>  =09=09NDBGL4(L4_ISPDBG, "isp%d, channel%d not active!", unit, cd->chan=
nelid);
>  =09=09splx(s);
>  =09=09return;
> @@ -602,6 +603,8 @@
>  =09=09sc->sc_state =3D ST_IDLE;
>  =09=09sp->pp_down(sp);=09/* tell PPP we have hung up */
>  =09}
> +=09else
> +=09=09printf("%s: sc->sc_state !=3D ST_CONNECTED\n", __FUNCTION__);
>
>  =09splx(s);
>  }
> --- layer4/i4b_l4.c.orig=09Tue Jan 21 20:58:33 2003
> +++ layer4/i4b_l4.c=09Tue Jan 21 21:11:22 2003
> @@ -464,6 +464,8 @@
>  =09=09(*cd->dlt->line_disconnected)(cd->driver_unit, (void *)cd);
>  =09=09i4b_unlink_bchandrvr(cd);
>  =09}
> +=09else
> +=09=09printf("%s: cd->dlt is NULL\n", __FUNCTION__);
>
>  =09if((cd->channelid >=3D 0) && (cd->channelid <
> ctrl_desc[cd->controller].nbch)) {
>
> ---
> Gary Jennejohn / garyj@jennejohn.org gj@freebsd.org gj@denx.de


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?200301220933.18435.ari.suutari>