Conference netcad::hub_mgnt

    any help or suggestions on where I can take this problem in .0?
    What I am looking for is the expected power connection of a DETMI to at
    DESBF when both power up at the same time.
    
    thanks
    ...scott

    I have some DR90Ts's and PEswitches configured in my lab.
    Maybe I can re-create the powerup situation. I'll see if I can 
    establish some observations.
    The only thing you didn't make clear is if either or both the 
    PEswitch or DETMI are stand-alone. IE: powered by a brick or docking
    station as required by each.
    
    Bob

    Oookay, I think I may have re-created what you saw Scott.
    First some data....
    The DETMI looks like it typically takes about 30 seconds to complete
    its self test and start looking for a link on either its UTP ports,
    its thinwire, or the AUI out the back. I powered up the DETMI several
    times to make sure of this time.
    The PEswitch 900TX typically takes about 50 seconds to complete its
    self test, and another 30 seconds to bring a link up (15 seconds in
    learning state, plus 15 seconds in pre-forwarding state).
    So with a PEswitch already powered on it takes about 30 seconds for
    a DETMI link to come up.
    With a DETMI already on, it takes a minute and 20 seconds for the
    PEswitch to bring up a link.
    With both powered off and then powered up, it will still take at
    least 1 minute and 20 seconds for a link to come up.
    Now, for the wierdness I think you may have seen....
    Once after powering them both up simutaneously, the DETMI seemed to 
    complete its self test, but shortly after this, it seemed to be
    sending out what is referred to as a "jabber" packet, as the traffic
    led was on solid. At the PEswitch end, when it completed its self
    test (50 seconds), the traffic led for the port which was physically
    connected to the DETMI, was also on solid. This lasted for about
    3 minutes, after which the DETMI saw the link, and then the PEswitch
    too saw the link.
    I believe that what might be happening is that with the thinwire port
    un-terminated, and seeing no other active lan, it sits on the thinwire,
    sees an un-terminated thinwire lan, and sees multiple collisions because
    of the un-terminated unused thinwire port, and sends out a jabber packet
    for another couple of minutes.
    It seems to eventually correct itself and starts hunting through the
    ports looking for an active lan.
    Does this sound like what the customer might have seen?
    
    Bob
    

    re: .2 - as you figured out they are all standalone.
    
    What my customer saw was that it never connected without repowering on
    the DETMI.  In other words the DESBF port never connected.
    
    I will ask the cusomter to terminate the thinwire and see if they can
    recreate the problem.
    
    thanks for this update.  I'll let you know if it contiure.s  It will be
    a couple of dasy before I get back to you.
    
    ...scott

    >What my customer saw was that it never connected without repowering on
    >the DETMI.  In other words the DESBF port never connected.
         
    This is ummmm "interesting"... When my DETMI fails to connect to
    the AUI, the DESBF sees the link (IE: sees the DETPM MAU), every
    time. In other words, the DESBF - DETPM MAU link portion is seen by 
    the DESBF. The rest of the logical link, (the AUI side of the MAU
    into the DETMI) is disconnected. As long as the MAU has power (from
    the AUI conn. of the DETMI), the DESBF will see the utp link and
    will come up into forwarding. It's the DETMI end which is broken
    somehow. I've asked the opinion of someone in the repeater engineering
    group, and he says that perhaps the rear cover (which houses the
    little pc board that provides the mechanical transition between the
    48 pin Secretariat connector and the rear AUI connector may be 
    presenting the wrong slot ID value to the DETMI internal logic.
    I've got to verify this tomorow morning with someone else. Someone
    else mentioned a feature the DETMI has where via management (HUBwatch),
    one can set the DETMI in one of 3 modes, auto (auto selects between
    the side thinwire port and the rear AUI), thinwire, or AUI. The
    solution for the customer might be simply to select AUI, and save
    this value to the internal nvram of the DETMI. Then it will always
    power up and look for the AUI *only*, and won't ever look at the
    thinwire.
    
    Bob