Linux-ATM v0.52 w/Linux kernel 2.1.129

To: pca200e-linux@os.inf.tu-dresden.de
Subject: Linux-ATM v0.52 w/Linux kernel 2.1.129
From: "Gordon M. Taylor" <gordon@irongrip.itd.nrl.navy.mil>
Date: Wed, 09 Dec 1998 17:05:35 -0500
Cc: oferrall@itd.nrl.navy.mil
Content-Type: text/plain; charset=us-ascii
Reply-to: gordon@cs.nrl.navy.mil
Sender: owner-pca200e-linux@os.inf.tu-dresden.de


	Hello --

	First a little background:
	I have installed Linux Kernel 2.1.129 and applied the Linux-ATM
	0.52 patch along with the PCA-200e v0.4 patch.  I have this setup
	installed on 5 p5-133 machines with identical hardware with
	one exception:  2 of the machines are running the PCA-200e ATM
	interface card, and 3 of the machines are running an Efficient
	Networks ATM interface card.  While the PCA-200e patch is installed
	on all 5 machines, it is not configured in the kernel on the three
	that are running the ENI hardware.  The ATM network driver is
	compiled as part of the kernel and not as a KLM on all 5 machines.
	In addition, the PCA-200e driver is not part of the kernel on the
	machines that are running the ENI hardware, and vice versa.
	When I compiled Linux-ATM v0.52, I defined STANDARDS equal to
	-DUNI31 -DALLOW_UNI30.
	Linux-ATM v0.47, with the same STANDARDS definition, works fine
	on all of these platforms.

	On to the problem:
	When I upgraded the above machines that contained FORE hardware,
	I got the following output upon starting the L-ATM daemons
	immediately after initializing signaling on the corresponding
	port on the ATM switch:

[root@javelin gordon]# /usr/sbin/atmsigd -b
atmsigd:SIGD: /etc/atmsigd.conf not found. - Using defaults.
atmsigd:SIGD: Linux ATM signaling UNI 3.0, version 0.52 on 0.0.5
atmsigd:SIGD: Acting as USER side
atmsigd:KERNEL: Added local ATM address 47.0005.80FFE1000000F21A336B.00204808C1
36.00 at itf 0
atmsigd:SSCOP: layer management - error O "VT(CC)>=MaxCC"
atmsigd:SSCOP: layer management - error O "VT(CC)>=MaxCC"
atmsigd:SSCOP: layer management - error O "VT(CC)>=MaxCC"
atmsigd:SSCOP: layer management - error O "VT(CC)>=MaxCC"
[root@javelin gordon]# /usr/sbin/ilmid -b
atmsigd:SSCOP: layer management - error D "BGREJ PDU"
[gordon@javelin gordon]# /usr/sbin/atmarpd -b
atmarpd:ARPD: Linux ATM ARP, version 0.52

	When I create the atm0 interface and attempt to set up a vc to an
	arp server, I get the following output:

[gordon@javelin init.d]# /usr/sbin/atmarp -c atm0
[gordon@javelin network-scripts]# ifconfig atm0 132.250.97.120 netmask 
255.255.255.0 broadcast 132.250.97.255 up
[gordon@javelin network-scripts]# /usr/sbin/atmarp -s 132.250.97.0 
47.0005.80ffe1.0000.00f2.1a33.6b0020481a336b.00 arpsrv
[gordon@javelin network-scripts]# atmsigd:SSCF: sscf_send invoked in state 2/2
atmarpd:IO: [2]connect: Network dropped connection on reset
atmsigd:SSCF: sscf_send invoked in state 2/2
atmarpd:IO: [2]connect: Network dropped connection on reset
atmsigd:SSCF: sscf_send invoked in state 2/2
atmarpd:IO: [2]connect: Network dropped connection on reset
atmsigd:SSCF: sscf_send invoked in state 2/2
atmarpd:IO: [2]connect: Network dropped connection on reset
atmsigd:SSCF: sscf_send invoked in state 2/2

	These messages continue to scroll in the window until I issue
	the following:

/usr/sbin/atmarp -d 132.250.97.0 arpsrv


	All 5 of these machines are connect to a FORE 200 bx switch with
	"c" series netmods running ForeThought 5.1.x software.  Here is 
	the output from the debug port on that switch:

Successful connection using L-ATM v 0.47:

tAsx[X]:   debug:  UNI[ 1] --> rx SETUP: cref = 0x4
tAsx[X]:   debug:  UNI[ 1]   BLLI layer 2 = LLC_l2_proto_id
tAsx[X]:   debug:  UNI[--]   q93b_check_combination_per_uni40_A9_2: bbc=0x10, 
atc=0x0, traffic=0x1002, qos=0x4, tagging=0 serv_type = 0x5, direction = 0x0 
un = 0x2
tAsx[X]:   debug:  UNI[--]   q93b_check_combination_per_uni40_A9_2: 
fore_scheme=0x50
tAsx[X]:   debug:  UNI[--]   q93b_check_combination_per_uni40_A9_2: bbc=0x10, 
atc=0x0, traffic=0x1002, qos=0x4, tagging=0 serv_type = 0x5, direction = 0x1 
un = 0x2
tAsx[X]:   debug:  UNI[--]   q93b_check_combination_per_uni40_A9_2: 
fore_scheme=0x50
tAsx[X]:   debug: CALL_FWD Calling Party: 47.000580ffe1000000f21a336b.00204808c
136.00
tAsx[X]:   debug: CALL_FWD Called Party:  47.000580ffe1000000f21a336b.0020ea001
43a.00
tAsx[X]:   debug: CALL_FWD cc_route_and_alloc_resource_pp_setup: routing 
return value -> 0x0
tAsx[X]:   debug: CALL_FWD cc_route_and_alloc_resource_pp_setup: route found, 
outport 0xb0000
tAsx[X]:   debug: CALL_FWD cc_setup_uni_vcls: ingress UNI[1|0] allocated 
vcl-pair on VCI 92
tAsx[X]:   debug: CALL_FWD ingress UNI [1|0]: vpi = 0 vci = 92, vcl: in = 
0xc9b438  out = 0xc9b4e8
tAsx[X]:   debug: CALL_FWD cc_setup_uni_vcls: egress UNI[11|0] allocated 
vcl-pair on VCI 96
tAsx[X]:   debug: CALL_FWD egress UNI [11|0]: vpi = 0 vci = 96, vcl: in = 
0xc9b2d8  out = 0xc9b388
tAsx[X]:   debug: CALL_FWD cc_init_vcc_index: port=1 vpi=0 vci=92
tAsx[X]:   debug: CALL_FWD cc_insert_vcc_in_vcc_db: inserted vpi 0 vci 92 
linkid 1 in splay tree
tAsx[X]:   debug:  UNI[11]   <-- tx SETUP: cref = 0x135
tAsx[X]:   debug:  UNI[ 1]   q93b_call_proceeding: ccb = 0xc96198, cref = 
0x800004
tAsx[X]:   debug:  UNI[ 1]   <-- tx CALL PROCEEDING: cref = 0x800004
tAsx[X]:   debug:  UNI[11] --> rx CONNECT: cref = 0x800135
tAsx[X]:   debug: CALL_FWD cc_check_connids: vci_out = 0x60, vcl_out = 0xc9b388
tAsx[X]:   debug:  UNI[ 1]   <-- tx CONNECT: cref = 0x800004
tAsx[X]:   debug:  UNI[11]   <-- tx CONNECT ACK: cref = 0x135
tAsx[X]:   debug:  UNI[ 1] --> rx CONNECT ACK: cref = 0x4
tAsx[X]:   debug:  UNI[ 1]   rx_connect_ack: no-op per 5.5.1.7, cref = 0x800004

Unsuccessful connection using L-ATM v0.52:

tAsx[X]: -ERROR-: Possible Uni 30 interface on link 1 Rejecting N(SQ) value  0 
in bgn pdu
tAsx[X]: -ERROR-: Possible Uni 30 interface on link 1 Rejecting N(SQ) value  0 
in bgn pdu
tAsx[X]: -ERROR-: Possible Uni 30 interface on link 1 Rejecting N(SQ) value  0 
in bgn pdu
tAsx[X]: -ERROR-: Possible Uni 30 interface on link 1 Rejecting N(SQ) value  0 
in bgn pdu
tAsx[X]: -ERROR-: Possible Uni 30 interface on link 1 Rejecting N(SQ) value  0 
in bgn pdu


	This message continues scrolling until atmsigd is killed on the 
	host.

	So now, the big question:  Can anyone tell me what's going on
	here?  The behavior is identical on both machines that have
	FORE hardware, but those machines that are using ENI hardware
	work fine.  As expected, if I go back to version 0.47  of the
	Linux-ATM software on the two PCs equipped with FORE hardware,
	everything initializes correctly and all 5 machines communicate
	properly.

	Thoughts and Miscellaneous Ramblings:
	Since the ENI driver does not exhibit the same problems, it would
	appear that atmsigd or ilmid (or both) is (are) not interacting
	properly with the FORE driver (e.g. atmsigd initializes the
	connection, and ilmid improperly attempts to do address
	configuration via UNI 3.0 rather than UNI 3.1 -- did the ilmid
	API change drastically between 0.47 and 0.52?).  However, since I
	haven't seen any other traffic on this list indicating a similar
	problem, I am inclined to believe that it could be something else;
	perhaps something unique in our setup here.
 
	Thanks in advance for your help,

	gordon

	


-- 

Gordon M. Taylor		    gordon@cmf.nrl.navy.mil
Washington, D.C.	   Naval Research Lab Connecton Machine Facility

"There was nothing like an appeal to honor.  It was a virtue that all craved,
even those who lacked it.  Fundamentally, honor was itself a debt, a code of
behavior, a promise, something inside yourself that you owed to the others 
who saw it in you."				-- Thomas L. Clancy, Jr.
Prev by Date: Re: PCA 200E traffic shaping support?
Next by Date: How to setup a CLIP?
Prev by thread: Please help to diagnose.
Next by thread: How to setup a CLIP?
Index(es):
- Date
- Thread
Home | Main Index | Thread Index