[cisco-nas] X.75 (LAPB-TA) sessions getting "stuck"? (AS5300, 12.3)

[Gert Doering]

Hi,

so now it had happened again... (the X.75-got-stuck thing).

On Fri, Oct 02, 2009 at 02:16:44PM -0700, Aaron Leonard wrote:
> I think the algorithm will always hit the first free vty.  So, if
> let's say vty 0 is in use and vty 1 is (somehow) messed up, but free,
> then the next LAPB-TA call would hit vty 1.  If, right after that,
> another LAPB-TA call were to come in, it might hit vty 2 and maybe be
> OK.
> 
> So if you could get the bad vty out of harms way (e.g. by removing
> "transport input lapb-ta" from it), then this might get you going
> again.

I think it is not stuck to the VTY, but to "the first, second, ... 
parallel X.75 session".

For a while, I could make X.75 work again by calling on two different lines
in parallel (the first one would reliably get stuck, the second worked
for a few calls) - so it wasn't "all of the X.75 is broken, just the
first call".

I tried disabling the first few VTYs, but that didn't change anything -
the first call was still stuck, but on a higher VTY number now.

After a few tests, I now have two stuck X.75 sessions in parallel, 
and have no more test devices to make further calls...


Is there any trick to reset the internal state of the X.75 protocol 
machinery?

Like "remove lapb-ta autodetection from all ISDN interfaces" or so
(which didn't have any effect, btw)?

gert

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nas/attachments/20091103/4c7dde5f/attachment.bin>