Conference noted::decnis

3558.0. "No X25-calls, if DECnis is idle" by ZUR01::SCHNEIDER (Kurt Schneider, SW-Support Zurich) Tue Feb 25 1997 13:21

Hello,

	This is an X400 environment where an AXP-Unix-client 
can successfully pass on X.25 calls to the DECnis (V3.1.8)
if at the same time from the same node trace is running on that DECnis.
If the DECnis isn't busy with trace no outgoing X.25 calls can
be done. We managed to capture traces from a VAX at the time
the AXP-Unix-client was transfering its X400-messages.

	I am not sure if this LLC2 call gets cleared by the
DECnis or by the PSDN-switch. Can somebody verify the following
traces,

LLC2-DTE: dte-BOSFC3 / PSDN-DTE: DTE-4-0

-----------+----+---+-----------+<--------Packet-------->+---------------------
    Time   |Evnt|   |Name       |Chn Q Type     P    P   |Data                 
hh mm ss cc|    |Siz|           |    M         R/S  R/S  |                     
-----------+----+---+-----------+<---------------------->+---------------------
10:33:55.44|Rx  | 19|dte-BOSFC3 |005   CALL              |Called DTE 46711134000
                                |                        Calling DTE 11111119
                                |                        Data 03 01 01 00|
                                |                        |
10:33:55.46|  Tx| 20|DTE-4-0    |005   CALL              |Called DTE 46711134000
                                |                        Calling DTE 4711111719
                                |                        Data 03 01 01 00|
                                |                        |
10:33:55.58|Rx  |  5|DTE-4-0    |005   CLR   C=13 D=44   |
10:33:55.58|  Tx|  5|dte-BOSFC3 |005   CLR   C=13 D=44   |
10:33:55.59|Rx  |  3|dte-BOSFC3 |005   CLRC              |
10:33:55.60|  Tx|  3|DTE-4-0    |005   CLRC              |
10:33:55.60|Rx  | 17|dte-BOSFC3 |005   CALL              |Called DTE 46711134
                                |                        Calling DTE 11111119
                                |                        Data 03 01 01 00|
                                |                        |
                                |                        |
10:33:55.71|  Tx| 18|DTE-4-0    |005   CALL              |Called DTE 46711134
                                |                        Calling DTE 4711111719
                                |                        Data 03 01 01 00|
                                |                        |
10:33:55.98|Rx  |  5|DTE-4-0    |005   CLR   C=00 D=F1   |
10:33:55.98|  Tx|  5|dte-BOSFC3 |005   CLR   C=00 D=F1   |
10:33:55.99|Rx  |  3|dte-BOSFC3 |005   CLRC              |
10:33:56.00|  Tx|  3|DTE-4-0    |005   CLRC              |
                                                         

good call on LLC2,

13:44:04.51|Rx |RR 5 5
13:44:04.54|Rx |Clear Request/Clear Indication 5 DTE Clearing No information
13:44:04.57|Tx |Clear Confirm 5
13:48:25.36|Rx |Call Request/Incoming call 5 46711134000 11111119 03010100
13:48:30.05|Tx |Call Accept/Call Connect 5 46711134000 4711111719
13:48:30.07|Rx |I  5 0/0
13:48:30.12|Tx |RR 5 1

bad call on LLC2 where I see no difference...,

13:49:34.96|Rx |RR 5 5
13:49:34.97|Rx |Clear Request/Clear Indication 5 DTE Clearing No information
13:49:34.99|Tx |Clear Confirm 5
13:52:47.42|Rx |Call Request/Incoming call 5 46711134000 11111119 03010100
13:52:47.58|Tx |Clear Request/Clear Indication 5 Local Procedure Error
                                                 invalid calling DTE
13:52:47.58|Rx |Clear Confirm 5
13:52:47.59|Rx |Request/Incoming call 5 46711134 11111119 03010100
13:52:47.92|Tx |Request/Clear Indication 5 DTE Clearing 241
13:52:47.93|Rx |Confirm 5

Thank you for your help.

Regards
Kurt                                                        
    

In the initial trace the CLR is coming from the network, both times.

Try tracing at the LAPB level. I suspect you might see that the outgoing call
requests are malformed (i.e. length of called+calling DTE addresses is odd and
the trailing nibble is non-zero).

If this is the case, send me mail and I'll point you at a fixed image which
should solve the problem (it is currently being tested by a customer and will be
in V3.1-10).

As far as it working when trace is running - I'm guessing that's a fluke or a
happy coinicdence - my money is on a (known) bug in our CALL REQUEST packet
building ...

Antonio 

    Thank you Antonio,
    
    	I already adviced the customer to capture LAPB-trace of this event.
    It will probbably take some time until we have it. In the meantime why
    don't you send me the pointer to your fix so we could test it as well.
    If trace is not active we have a very fast reproducer. So I expect to
    see if your fix does help us very soon.
    
    Regards
    Kurt

Pointer sent.

Antonio

    Hello Antonio,
    
    	Your image fixed the problem. No call failures any more.
    
    Thanks for your help.
    
    Regards
    Kurt