Conference marvin::wanrouter250

	Are you running the original SSB release? If so, there were a number
	of problems that have since been fixed. You can pick up fix kits
	from the location given in note 815.

	

Hi,

I've installed both the ECO 01 and the 1.3.5 system image.

Ryan
[Posted by WWW Notes gateway]

	Well, as I understand it from .0, you are having problems with
	incoming calls on the WR90. Is that right?

	It would help if you could post the configuration (.NCL) files here.
	Also, have you tried tracing the WR90 X.25 DTEs, using CTF from the
	VAXen? This might give us/you a clue as to why the calls don't get
	through.

�     To aggravate matters, I can't see what the exact errors are, because, 
�     as soon as I try and setup the Event sink on the WR90 it crashes as 
�     soon as it finishes booting. All I can see is the 'Calls Failed'
�     and 'Illegal Packets' counters keeps increasing.

Are you saying the WR90 crashes if you have an event sink defined?.  If that
is the case and you are running V1.3.5, then can you submit an IPMT case.

As Walter  says,  can  we take a look at the .NCL script + any CTF trace you
can get. 

Mark

Hi,

below, I'll insert the NCL for the problem end. This isn't the latest one I
tried, but is nonetheless one that didn't work. Unfortunately, it's a 3 hour
trip for me to get an up-to-date version, since I've no way of dialling into 
their systems.

The configuration is absolutely straight-forward, using the basic settings in
the configurator, specifying PSS as the X.25 profile. The only difference 
between the working end, and the broken end is the direction of the DLM.
However, I did try and set up a DLM in the other direction with similar effect.

There's nothing in the *extra* files.

On a slightly different track, perhaps you can advise me about the following:

I've just spoken to a colleague of mine who did some original installation at
this site some years ago, and apparently there was a batch of modems that 
were a little suspect. He related a story of a DEMSA acting as a SNA gateway
(which is still there, although unrelated to my problem). They couldn't get 
this DEMSA to communicate over a 9600, V.24 line (same speed/interface as my 
problem). Eventually the Telco sent over an oscilloscope, and they discovered
that instead of sending "minus ones", the modem was sending out "zeroes". 
Apparently alot of comms equipment copes OK, but the DEMSA didn't. Since
the WANrouter 90 uses the same 50-pin interface/adapters as the DEMSA, I 
suspect that the background circuitry is very similar. Would it be reasonable
to suspect that this could be the cause of my problem ?

regards, and thanks for the prompt responses so far.
Ryan

PS (and this is serious), would anyone with vast experience/knowledge of 
this device (mine is a bit rusty, and I was never great on X.25) be 
interested in coming to South Africa to fix the problem ? My boss says 
he'll pay - we have $400K resting on getting it sorted out.
                                                           
Here's the NCL:

set ncl router type VR2$WR90
set ncl router parameter 2001010|X25L3=PSS|LAPB=PSS
set ncl nmvlscript sys$common:[mom$system]vr2_ptax01.bin
enable ncl nmvlscript
!
!
!		DEC WANROUTER CONFIGURATION SCRIPT
!		==================================
!
!	This script was produced on:	Tue May 13 20:27:24 1997
!	using the DEC WANrouter Configuration Utility Version :	V1.3
!
!
!	To use this script on a DEC WANrouter system, the script
!	must be processed by the NCL utility : sys$system:decrou$ncl
!
!
!
! This is an NCL script for the following DEC WANROUTER
!
! Node:  local:.ptax01
! MOP Client Name:  ptax01
! Hardware Type:  WR90
! Hardware Address:  00-00-f8-43-6f-16
!
!
!
! The tower set for the DEC WANrouter :
!
! {
!    (
!         [DNA_CMIP-MICE],
!         [DNA_SessioncontrolV3, Number=19],
!         [DNA_NSP],
!         [DNA_OSInetwork, 49::00-03:AA-00-04-00-FF-0F:20 ]
!    )
! }
!
! Create the Modules that are always present
!
create modem connect
create csma-cd
create mop
create hdlc
create ddcmp
create session control
create nsp
!
!
!
! Set up DTSS time differential factor. Use the following command,
! in which "time" is the positive(+) or negative(-) offset in
! minutes from GMT. For example if you are two hours behind GMT
! use:
!    set dtss local time differential factor  -2:0:0
!    or 3 hours ahead of GMT use
!    set dtss local time differential factor  3:0:0
!
set dtss local time differential factor -2:0:0
!
! Set up the Routing Module
!
create routing type L2Router , protocols { ISO8473  ,  Decnet Phase IV }
set routing phaseiv address 3.1023 , phaseiv prefix 49::
set routing manual L1 algorithm routing vector
set routing manual L2 algorithm routing vector
set routing phaseiv maximum address 1023 ,  phaseiv maximum area 63
set routing lifetime 63, maximum path splits 2
!
!
!
!  Create CSMA station : csmacd-0
!
create csma-cd station  csmacd-0 communication port ether-1
!
!
!
!
!
! Create X25 entities
!
create lapb
create x25 protocol
create x25 access
!
! Create default X25 entities
!
create x25 access security filter default
set x25 access security filter default  -
    acl (( identifier =( * ), access = ALL ))
create x25 access security dte class default
create x25 access security dte class default remote dte MATCHALL  -
     remote address prefix *
!
!
!
! Create and set Line :  serial-1
! to use device: serial-1
!
create modem connect line serial-1 communication port serial-1
set modem connect line serial-1   speed 9600
set modem connect line serial-1 modem control full
!
!
!
!
! Create and set DTE:  DTE-1
! and LAPB link:  DTE-1
! using Line:  serial-1
!
create lapb link DTE-1 profile  "PSS"
set lapb link DTE-1 physical line modem connect line serial-1 ,  -
    maximum data size 261 ,  window size 7
!
! Create and set DTE:  DTE-1
! using Line:  serial-1
!
create x25 protocol dte DTE-1 profile  "PSS"
set x25 protocol dte DTE-1 link service provider lapb link DTE-1 ,  -
    inbound dte class PSS ,  x25 address 10631449 ,  -
    incoming list  [[1..10]] ,  outgoing list  [[1..10]] ,  -
    minimum packet size 16 ,  maximum packet size 128 ,  -
    default packet size 128 ,  minimum window size 1 ,  -
    maximum window size 2 ,  default window size 2
!
! Create Local DTE Class: PSS
!
create x25 access dte class PSS type local
set x25 access dte class PSS local dtes -
    { DTE-1 }
!
! Create Local DTE Class: DTE-1
!
create x25 access dte class DTE-1 type local
set x25 access dte class DTE-1 local dtes -
    { DTE-1 }
!
! Commands to set OSI routing circuit : ethernet
! On device : csmacd-0
!
create routing circuit ethernet type csma-cd
set routing circuit ethernet data link entity csma-cd station csmacd-0
set routing circuit ethernet Manual L2Only Mode  FALSE
set routing circuit ethernet L1 cost 20 ,  L2 cost 20 ,  -
    L1 router priority 64 ,  L2 router priority 64
!
! Create and set Routing Circuit: RX25-IN-1-Head-Office
! It uses Template: RX25-IN-1-Head-Office
! It uses Filter: RX25-IN-1-Head-Office
!
create routing circuit RX25-IN-1-Head-Office type x25 static incoming
set routing circuit RX25-IN-1-Head-Office data link entity x25 access
set routing circuit RX25-IN-1-Head-Office Manual L2Only Mode FALSE
set routing circuit RX25-IN-1-Head-Office L1 cost 20 ,  L2 cost 20 ,  -
    manual data link sdu size 1492
set routing circuit RX25-IN-1-Head-Office -
    X25 filter { RX25-IN-1-Head-Office }
set routing circuit RX25-IN-1-Head-Office -
    template RX25-IN-1-Head-Office
!
! Create and set Template: RX25-IN-1-Head-Office
!
create x25 access template RX25-IN-1-Head-Office
!
! Create and set Filter: RX25-IN-1-Head-Office
!
create x25 access filter RX25-IN-1-Head-Office
set x25 access filter RX25-IN-1-Head-Office -
    call data mask %xffffffffffffffffffffffffffff ,  -
    call data value %xff0000004445436e65742d444c4d ,  -
    security filter DEFAULT ,  priority 1 ,  sending dte address 10631247
!
! Sample commands to set up the Session Control user names and password
!
! set session control privileged user fred , -
!    privileged password fred
!
!    Note : If you set the session control privileged user password
!    then the configurator will be unable to directly access the DEC WANRouter.
!
!    For example : It will be unable to directly set the script & image loading methods
!    the next time the router is booted.
!
!
create session control transport service service-1 protocol = '04'H
create session control application CML
!
!
!
! Execute the file containing the extra create ncl commands
!
@  sys$common:[mom$system]vr2_ptax01_extra_create.ncl
!
! Execute the file containing the extra set ncl commands
!
@  sys$common:[mom$system]vr2_ptax01_extra_set.ncl
!
!
! Enable the node address function cmip listener
!
!
rename node 0 new name  0:.ptax01
enable node 0 function cmip listener
!
!
! Enable the Routing Module
!
!
enable routing
!
! Enable the modules that are always present and
! require Enabling.
!
enable session control
enable nsp
!
!
enable csma-cd station csmacd-0
!
! Enable commands related to DTE: DTE-1
!
enable modem connect line serial-1
enable lapb link DTE-1
enable x25 protocol dte DTE-1
!
!  Commands to enable OSI routing circuit :  ethernet
!
enable routing circuit ethernet
!
!
!
! Enable the X25 Access Module and the X25 Routing Circuits:
!
enable x25 access
enable routing circuit RX25-IN-1-Head-Office
!
!
!   Commands to set up MOP loop back on Device: csmacd-0
!
create mop circuit csmacd-0  type csma-cd
set mop circuit csmacd-0 link name csma-cd station csmacd-0
!
!   Commands to set up MOP loop back on Device: serial-1
!
!
!  Commands to enable MOP loop back on Device: csmacd-0
!
enable mop circuit csmacd-0 function {  loop requester }
!
!  Commands to enable MOP loop back on Device: serial-1
!
! Execute the file containing the extra enable ncl commands
!
@  sys$common:[mom$system]vr2_ptax01_extra_enable.ncl
exit

As you  say,  a  really  dull script!.  I guess we need the CTF trace to see
whats  going  wrong.   Out  of  interest  do the X.25 and/or routing circuit
counters show up anything intersting?. 

ncl> show node <rtr> rou cir RX25-IN-1-Head-Office all
ncl> show node <rtr> x25 acc all
ncl> show node <rtr> x25 p dte * all

Mark

	..and, if you suspect modem/line level problems:

ncl> show node <rtr> lapb link DTE-1 all
ncl> show node <rtr> modem connect line serial-1 all


	..although an empty trace file would be just as conclusive.
	I don't suppose you can take a line analyser on-site?

	Apart from that, there is nothing obviously wrong in the script.
	I assume you've re-checked the DTE address and SVC channel ranges.
	Also, if your load host has VAX PSI, it might be worth checking
	to see that you are getting the profile (.PRF) files from the
	WR90 kit and not those from the PSI/DECnet kit.

    Hi,
    
    the only interesting counters are the 2 I mentioned earlier, on the
    X.25 protocol dte - 'Calls Failed' and 'Invalid (Illegal?) Packets 
    received' (?). They both seemed to climb (slowly) at the same rate.
    
    I haven't set up tracing (I was hoping to avoid it) yet, and I can't
    get back there until Thursday, since I'll be 1500 km away. But, the 
    customer will contact the Telco for me on Monday morning to request
    a scope and/or a new modem, and we'll see how we go from there.
    
    I don't think they've installed X.25 on the Alpha, which is the load
    host for the WANrouter 90. PSI is on the VAX, which they're hoping to
    dispose of soon (it's an 11/750 I think). But, I'll check the profiles
    when I'm there again.
    
    The more I think about it, the more convinced I am in my mind that
    there's a voltage problem out of the modem, so I'll sleep easily until
    that's been checked.
    
    Oh, and we did try another V.24 cable, with no change - so the only
    thing left to swap is the modem.
    
    thanks again, I'll chat to you again next week. Enjoy your weekend.
    
    Ryan

    OK,
    
    I'm back to try again. Unfortunatly I'll only get back to the site on
    Monday, but while I was away, they tried replacing the modem and cables
    on the WANrouter, neither helped.
    
    We got NO cooperation from the telco, so we did it all ourselves.
    
    The replacement modem came from our office and our local X.25
    connection (previously on a DEMSB, now on a DECNIS). It seemed to make
    no difference at all (although I wasn't there to check any counters),
    with no X.25 circuits coming to life.
    
    I am going out there now on Monday, armed with a RouteAbout Access (I'm
    ready to try anything now). I'll also be trying to set up tracing, and
    maybe try and get the event log going again.
    
    On the subject of the event log, is there anything on the host system
    that would cause the event logger to crash on the WANrouter; perhaps a
    suspect version/eco level of DECnet ?
    
    thanks & regards,
    Ryan

�     On the subject of the event log, is there anything on the host system
�     that would cause the event logger to crash on the WANrouter; perhaps a
�     suspect version/eco level of DECnet ?
  
No. To solve the event dispatcher problem we need the dump. 

Without the event log we need all the counters you can find and a CTF trace...

Mark
  

Hi,

I managed some more testing yesterday.

I tried each of the following:
1) a DLM from the branch WANrouter to the central WANrouter
2) a DLM from the central VAX to the central WANrouter
3) replacing the branch WANrouter with a RouteAbout Access EW

Neither 1 nor 2 worked, but 3 did. I did a few other things, but these are
the interesting ones.

The conclusion I have come to is that the WANrouter is not accepting an
incoming DLM, since outgoing connections from the WANrouter seem to be fine.
The remote site reports 'Remote DTE cleared' in the DECnet IV event during
the VAX's attempts to establish the DLM to the WANrouter. I went through all
the access and security filters and X.25 templates, and could see nothing 
that would indicate a problem. As with the WANrouter, on the RouteAbout, I did
an absolute basic X.25 config, and it worked fine.

I checked the X25 profiles - and I've definitely got the right files.

On the event dispatcher crashing, I tried creating the bits manually, 
and as soon as I try to ENABLE the sink, then the router crashes. There
is a dump in JOBURG""::RESOURCES:[FAL.VR2]VR2_CUSX01.DMP. Also in that 
directory is a CAPTURE.LOG, which is a log of all the counters and 
characteristics I could remember to capture. In addition, there's the 
NCL scripts for CUSX01 (the central site) and PTAX01 (the branch), although 
you've seen that they're quire boring.

I won't be back there today, but should be back on Wednesday, and I'll do 
the CTF trace.

regards
Ryan
[Posted by WWW Notes gateway]

	From the counters, it looks very much like there is nothing
	wrong with the physical or datalink layer.

	I suspect the clue is the following:
	
>    Diagnostic Packets                = 0
>    Illegal Packets                   = 44
>    Reject Packets                    = 0


	From your description, it most likely that there is something in
	the call accept packet that the Wanrouter is objecting to.
	It may also be that the call is getting cleared with a Clear
	packet that WR90 does not understand.

	We really do need the CTF trace in this case.

    Hi,
    
    in the same area (JOBURG""::[.vr2]), are 2 trace files, dte.dat and
    lapb_dte.dat. The first is a trace of just the dte, the second of the
    dte and the lapb link.
    
    Ryan

14:22:58.87|Rx  |   32|001   CALL              |Called DTE 10631247
                      |                         Calling DTE 10631449
                      |                         Facilities 03 00 42 08 08
                      |                         Data FF 00 00 00 44 45 43 6E 65
                      |                        |
                      |                        |
14:22:58.88|  Tx|    5|001   CLR   C=00 D=42   |



        According to my list of diagnostics, 42(hex) is "facility parameter
        not allowed".

        In fact there are two oddities here. First the incoming
        call is trying to negotiate a packet size of 256 (42 08 08), when
        the maximum packet size has been set to 128 in the script file.

        Second, the call seems to be coming in on Closed User Group 00 (03 00).

	I thought initially that it was the packet size that was causing the
	problem, however the code should negotiate this down. So it looks like
	it is the CUG facility that is causing the problem. Where is this
	coming from? Is it inserted by the PSDN?

	You may need to define the appropriate CUG for the WR90.

    Hi,
    
    the dte is definitely in a closed user group, but my understanding is
    that it shouldn't matter - it certainly doesn't on our other platforms
    (including PSI and DRS). I will try defining it and see if it makes a
    difference.
    
    I'll also modify the packet size just in case. I hadn't worried about
    it, because I understand that to be a negotiated value anyway.
    
    Ryan
    
    

    Hi
    
    I checked the DTE parameters with the PSDN, and the DTE's do have a max
    data of 256. Changing that didn't seem to make a difference, as you
    suspected.
    
    I've tried setting up the cug, and the diagnostic 42 has gone away, and
    it now seems as if there's DLM negotiating going on and then clearing
    later on.
    
    Having never setup a cug before, I'm not sure that I got it right.
    
    Can you give me a 1-2-3 on the setup, so I can make sure I got it
    right? Also, do I need to include the cug setup in the NCL scripts and
    recompile/reboot the WR ?
    
    regards,
    Ryan

    Hi,
    
    I'm now getting the circuit coming up, followed by 'packet format
    errors' on the VAX system. The packets contain a large string of
    AAAAAAAAAAAAAAAA, plus some other stuff. Does this sound familiar ?
    
    Ryan

    
>    I've tried setting up the cug, and the diagnostic 42 has gone away, and
>    it now seems as if there's DLM negotiating going on and then clearing
>    later on.
    
>    Having never setup a cug before, I'm not sure that I got it right.
 


	If the call is being accepted and then cleared by Routing you have 
	probably got the setup right. There is, most likely, some other
	problem. More counters; more tracing?

>    Can you give me a 1-2-3 on the setup, so I can make sure I got it
>    right? Also, do I need to include the cug setup in the NCL scripts and
>    recompile/reboot the WR ?
    

	Well, I'm a bit rusty on this. It looks like the configurator
	doesn't do it for you :-(. In that case you will need to add
	a line such as

	CREATE X25 PROTOCOL GROUP X

	to the extra create (NCL) file.

	And:

	SET X25 PROTOCOL GROUP X TYPE CUG
	SET X25 PROTOCOL GROUP X MEMBERS {(DTE=DTE-1, INDEX=0)}

    I at last have a working circuit !
    
    Thanks for all your help.
    
    I forced the packet size on the Routing Circuit RX-? to 128, and the
    problem with the packet format error went away. I probably need to do
    some more experimentation around those packet sizes, but that can wait.
    
    I now have to deploy 6 WANrouters in remote branches, in addition to
    the central one. Now that I have one workig config, I can carry on.
    
    I hope you don't hear from me again soon, but you might, since if I'm
    successful with the DLM's, I'll be migrating them to DA circuits.
    
    thanks again & regards.
    Ryan

�     I forced the packet size on the Routing Circuit RX-? to 128, and the
�     problem with the packet format error went away. I probably need to do
�     some more experimentation around those packet sizes, but that can wait.

You really  should  not  have to do that.  Whats going to happen now is that
fragmentation  &  reasssembly  will  be  taking  place  at the network layer
(routing).

You said  that  when  the default was used (1492 I think) the VAX complained
about  packet format errors.  Any chance we could get a CTF trace of the DLM
startup  sequence  from  the  WR90?.  You can use either the routing or X.25
tracepoints.   Any  chance  you  can get an accurate transcript of the error
being reported by the VAX?. 

We did  have  some  early problems with DLM circuits when used with a packet
size  of  128  or  less, but these should have been fixed by 1.3.5.  Can you
just confirm that the image is V1.3.5. 

Mark

Hi,

I'll try and get the info you asked for when I'm back there tomorrow. 

I have to deploy another 5 sites, so I should be able to do some 
experimentation.

BTW, do I need to IPMT the EVD crash from here, or can you use the crash
dump without me raising the IPMT ?

Ryan
[Posted by WWW Notes gateway]

>BTW, do I need to IPMT the EVD crash from here, or can you use the crash
>dump without me raising the IPMT ?

	I'm afraid that the Wanrouters are definitely in maintenance
	only mode, so we will need an IPMT case if we are to allocate
	time to this problem.

    Hi,
    
    sorry, I obviously confused myself and you. The 128 byte packet is in
    the X25 Access Template for the Routing Circuit. The Routing Circuit
    still has the 1492 bye packet size.
    
    I did the second site today without any major problems, except that
    there was no WANrouter software on the remote site - not even MOP was
    configured. Over a 9600 X.25 line, it takes a few hours to copy over
    the 15MB of data, so I just created the .bin at the central site and
    copied it and the .sys file over and everything was fine.
    
    I'm not going to chase the EVD problem - this customer is keen to go
    over to a RouteAbout-based solution, and will probably be getting rid
    of his brand-new WANrouter 90's soon.
    
    Thanks again.