Conference ozrock::x25_osf

879.0. "invalid calling DTE" by UTOPIE::BRAUN_R () Thu Mar 27 1997 05:48

(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

Firstly the latest kit for X.25 is WAN Support V2.0a.  There are
numerous fixes in this kit, which make it a worthwhile upgrade.  The
release notes contain more information.  Though, after a quick scan,
I couldn't see anything which would affect this problem.

Secondly, I'm not sure what you're tracing.  Are you tracing the link
between the DECnis and PTT, or between your Host and DECnis?  

The upgrade from DECnet 3.0 to 3.2B seems to be the determining factor.
For LLC2, we use DECnet's DLI code.  It would be also worth describing
this problem in the DECnet conference, in case this problem lives in the
DLI code.

It may be helpful to copy the trace into this notes conference, and be
specific which side of the link is being traced.

Regards,
Matt.

see DECNIS #3581

this problem is solved with DECnis V3.1.10

best regards
martin
(standin for ralph)