Conference noted::dnu_osi

2151.0. "invalid calling DTE" by UTOPIE::BRAUN_R () Wed Mar 26 1997 11:42

(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

I'd say it was the DECNIS, Antonio has had a number of goes at fixing the
pad-with-nonzero problem and he thinks the latest fix kit solves it.

By the way, recent versions of dtf will show +NON-ZERO-PAD if it finds non-zero
pad in the DTE addresses specifically to catch this problem.

John

>> I'd say it was the DECNIS, Antonio has had a number of goes at fixing the
>> pad-with-nonzero problem and he thinks the latest fix kit solves it.

yes, it's fixed with DECnis V3.1.10.

see DECNIS #3581

best regards
martin
(standin for ralph)