🚀 go-pugleaf

Although this news group is not necessarily the best group to post this message
to, I think it is relevant to many people who read about FDDI and therefore
might be helpful to some.

This message may seem a bit long, but it is a summary of a months effort in 
trying to find the answer to a problem.  

Let us create a picture.  You purchase Sun S-BUS fddi cards for your workstations
and would like to connect these to your server.  After having a lot of problems
with third party vendors not keeping up with OS changes you decide to buy
your FDDI for the Suns from Sun.  Nothing strange so far.  Now you have all these
sun S-bus single attachment stations and a concentrator to hook them together
and you want to connect up your server.  What type of server does the average
company have?  Possibly a VME based system?  So, you buy a SUN FDDI DX/2.0 
card for 10k in hopes that your network will work great.  In the mean time
you have other products such as SGI and DEC equipment that you will be using
too as well as network management software.  Wouldn't it be great if it all
played together nicely?

Well, 6 months ago we went through such a scenerio.  We bought the S-bus
cards and the DX/2.0 controller.  We got the SGI stuff and the concentrators
and put it all together.  We even built our own stations.  When we put it
all together we found a little problem.  All the workstations work fine
except the Server.  The SGI has fddi visualizer software on it which makes
it neat to see the mib information on the network and to see the place of
problems.  The problem?  The FDDI visualizer shows everything except the
sun server on the ring and refuses to let you look at the MIB information.
Is is an SGI problem?  We thought so.  We worked on it for a bit, then started
using the sun SNM to try to figure out what was going on.  It turned out that
even the Sun SNM could not properly look at the MIB of the Sun FDDI DX/2.0.

Well, after realizing what was going on, and isolating the problem to Sun,
it turns out that the driver for the Sun server fails and core dumps when
it starts.  There are two patches which might have been related, so we got
them.  No fix here.  The smtd driver still crashes.  O.K.  No problem, we
have a maintenance agreement with Sun.  I placed a call to Sun and they 
acknowledged the problem and took down the information and we even got them
a core dump.  All seems to be in order.  NOT!

Two weeks later our maintenance agreement is up for renewal and in the process
Sun tells us that the FDDI DX is not a supported sun product.  They have no
plans for an upgrade and will not put it on our maintenance agreement.  They
did say that in the event that a decision was made to put it on the maintenance
schedule, we could add it to the contract.  NOT again!  Our contract office
will not modify the contract until the next time it is up for renewal.  

So, what do we do.  We spent 10k (actually we bought 2...so 20k) on something
to allow our workstations connect to the server (the recommended Sun configuration)
and find that Sun gladly took our money for a product that does not work.  
This is obviously not an isolated problem because I have made contact with a
number of other people who are having the same problem and are just waiting
(possibly hoping) that Sun will come to their senses and do the right thing here.
I have urged them to complain as much as possible.

In any case, the lesson learned is that you cannot necessarily trust that a Sun
product will really be supported even if you bought it only 6 months ago.  
Additionally, Sun apparently does not forsee FDDI as a viable means to connect
workstations to servers since they don't support the only means to connect
the two together.  If you have network management software that tries to 
map out the ring based on the MIB information (neighbor information) and you
have a Sun FDDI DX/2.0 in the network, don't expect it to work.  Pull the
sun out and everything will be fine.  

Want to verify this operation to yourself?  On a sun4 with the FDDI DX/2.0
installed, kill look for a core in the root directory...this was caused when
the system booted up.  Delete the core.  Now, kill the smtd daemon with
smtd_kill.  Start the daemon again with the -d option.  You will see
a number of frames go out and then you will get an srf_response and it will
get a Segmentation Violation.  The following is a exact dump of the operation 
with just two Sun stations on the network.  I put just these two to show that
no other station other than the sun was causing the problem.

sunoco #smtd_kill
sunoco #smtd -d
SUN MICROSYSTEMS INC, SMTD V6 R0.7
fddi0: nif_request v=0x1 t=0xaa55 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa56 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa57 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa58 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa59 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa5a s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: srf_announce v=0x1 t=0xaa5b s=10-0-4-f0-7c-2b i=0x38 sllw=0xf041 
Segmentation fault (core dumped)
sunoco #

You will then have a core in whatever directory you were in. 

Maybe Sun isn't the great company I put so much trust into.  It was an expensive
lesson.

Some followup information...I did this with both the dynamic and static linked
versions of the FDDI DX smtd software and had the same results.  You can see which
of these you are using by looking at the symbolic link /usr/etc/smtd.  If
it points to smtd_static you are running the static linked driver.  If it
points to smtd_shared, you are running the dynamic linked code.  

One other test...I got the smtd drive from a Sunlink card and performed the
same test.  The output is as follows:

sunoco #smtd_kill
sunoco #smtd -d
SUN MICROSYSTEMS INC, SMTD V6 R1.0
fddi0: nif_request v=0x1 t=0xaa66 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa67 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa68 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa69 s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa6a s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa6b s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa6c s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: nif_request v=0x1 t=0xaa6d s=10-0-4-f0-7c-2b i=0x28 sllw=0xf04f 
fddi0: srf_announce v=0x1 t=0xaa6e s=10-0-4-f0-7c-2b i=0x38 sllw=0xf041 
Segmentation fault (core dumped)
sunoco #

This was tried with both the shared and static versions also.  

For the past month I have tried everything that I can think of to get this
fixed and experimented with every kernel configuration that Sun has recommended.
The Sun Tech support said they would work on the problem, but without maintenance
I don't see any means to get the solution.  Thank you Sun...was it good for you!

---
Scott Hiles
whiles@relay.nswc.navy.mil

Standard disclaimer:
  The opinions expressed are those of my own and do not necessarily 
  reflect those of the DOD or the Navy.  I accept full responsibility.