Conference noted::decnis

3581.0. "invalid calling DTE" by UTOPIE::BRAUN_R () Wed Mar 26 1997 15:02

(cross-posted in DECNIS, X25_OSF and DNU_OSI)


Hi all,

my customer has Digital-UNIX 3.2 (OSF1 anut01 V3.2 69.73 alpha) and 
X.25 for OSF/1 2.0. There is a LLC2-connection to a DECNIS, acting
as X.25-gateway to the public X.25-network.
They are using TCP via X.25 (local xw0-interface = LLC2).
DECNIS is 3.1.7.
Everything worked o.k., until they upgraded from DECnet-OSI 3.0 ?
to DECnet/OSI for Digital UNIX V3.2B-0 (Rev. 23). 

There is an application connecting via TCP (and X.25). This is a
rather normal TCP-connection, sending a single SYN (connection setup
packet). Since the upgrade, this application does not work anymore
(connection remains in state SYN-SENT). From CTF-traces we saw
a X.25 rejection with C=13, D=44 sent to the DECNIS, acting as X.25-DTE.
D=44 means "invalid calling dte". From CTF-traces everything looked o.k.,
but the guy from the PTT told us, there are non-numeric characters after
the calling DTE-nr (10 digits including subaddress in our case) -->
contradiction to the CCITT-rule (has to be filled with "0"s).
CTF (at least on L3) does not show these invalid characters.

But there is a rather strange bypass at the moment:
When doing a ping to the other location, the first few packets are lost, but 
ping does send the next packet one second later. If there is no X.25-session 
for the IP-destination yet, a new one will be created.
"Fortunately" the 3rd or 4th attempt does create a valid X.25 call request
(at least with one binary "0" after the callind DTE address). After this,
all suqsequent pings will be o.k. (using the established X.25-session)
and also the application (not doing the extensive retries as ping) does work
now. 
The destination can be reached now for these (and new) connections.
But after a while without data being sent (should be some X.25 hold timer) 
the game starts again (if a new X.25-session is required)


We've checked the ncl-Files (not changed from the upgrade), everything 
else is looking o.k., but there is a little bit uncertainty about the
DECNIS upgrade history, currently 3.1.7.

In every case, this seems to be a pointer problem, creating some garbage
behind the DTE-nr. From the notes I found similar problem with other X.25-
products. 
In our case, it should be the DECNIS, as this is the X.25-DTE 
generating the X.25 request on the line, but the problem occured
after the upgrade of DECnet-OSI (according to the customer)

Question:

     The external DTE-nr is stored in the DECNIS only, but is it possible,
     that the DECNIS is appending the subaddress coming from the access node's
     template (via LLC2 or GAP) without any checking, therey appending
     also garbage characters arising from some bug in the host's software
     (e.g. DECnet/OSI) ?????  

Any help will be highly appreciated

Thanks,
Ralph

> packet). Since the upgrade, this application does not work anymore
> (connection remains in state SYN-SENT). From CTF-traces we saw
> a X.25 rejection with C=13, D=44 sent to the DECNIS, acting as X.25-DTE.
> D=44 means "invalid calling dte". From CTF-traces everything looked o.k.,
> but the guy from the PTT told us, there are non-numeric characters after
> the calling DTE-nr (10 digits including subaddress in our case) -->
> contradiction to the CCITT-rule (has to be filled with "0"s).
    
    The DECnis is at fault. V3.1-9 fixes this; however, since you must be
    using X25 Relay, V3.1-9 is no good to you: you'll make the call but the
    DECnis will crash as soon as the call is closed. V3.1-10 is being built
    soon (possibly right now) and should be out very soon. If you need an
    experimental image before then, send me mail and I'll build one.
    
> CTF (at least on L3) does not show these invalid characters.
    
    True (at least for CTF on VAX). You can see it on a LAPB trace but
    you'll have to do the decode yourself. I'll see if I can fix CTF X25L3
    tracing on VAX to report this problem; you'll have to log a QAR or IPMT
    to get DECnet/OSI on Unix changed if it has the same restriction.
    
    To be honest I'd switch to using DTF for this kind of thing: it does a
    whole host of things that CTF never will.
    
> The destination can be reached now for these (and new) connections.
> But after a while without data being sent (should be some X.25 hold timer) 
> the game starts again (if a new X.25-session is required)


    The problem is random: the byte in question should be cleared but it
    isn't. The DECnis, X25 Gateway and PSI (on VAX) all share 99% of the
    code which provides the X.25 functionality. A change made for
    DECnet/OSI V5.7A introduced the bug; it was fixed for DECnet/OSI quite
    a while back (perhaps several years) but it was only recently found to
    be a problem for X25 Relay connections. V3.1-10 contains a fix for this
    problem.
    
    Antonio
    

    Thanks!
    
    I'll check with the customer if he can wait for 3.1.10.
    
    Regards,
    Ralph

    
>>    I'll check with the customer if he can wait for 3.1.10.
    
our customer use V3.1.10 for one week now, and it works fine now.

thanks
martin 
(standin for ralph)