Conference netcad::hub_mgnt

    I experienced exactly the same behaviour of my bridge yesterday.
    I will try to solve the problem today using the procedure described in
    notes 1193.* and 1391.*. 
    I will let you know the result.
    
    Rgds.....P.

May I ask how you performed the upgrade?  Did you follow the instructions in the
HOW2LOAD.TXT file or the DECbridge 900MX release notes that were supplied with
the DEChub Consolidated Firmware Kit V1.1?  I ask this because it is possible
that if you tried to do a MAM-assisted upgrade from v1.2.1 to v1.4.0 it might
corrupt the firmware image.  You must perform a direct load of v1.4.0 (i.e.
assign the bridge an IP address and use that address to perform the load).  If
you did this, then I do not know why the load failed.

...Roger...

    I did a direct load (no MAM assisted upgrade).
    
    So, this morning I tried to get my bridge up and running with the
    assistance of one of our UNIX-specialists. We used the procedure as 
    described in note 1193 and 1391.
    
    We managed to load the v1.4 firmware but the module always
    reinitializes it self after a few seconds "MODULE OK" lit-up.
    
    So, after power on the "POWER OK" LED lits and the module goes into a
    sequence of selftest and associated LED-patterns going on and off.
    After a while "port state #" of port 2 light yellow and a few seconds
    later "MODULE OK" comes on. Again a few seconds later the module
    reinitialize.
    
    Does anyone knows a workarround for this strange behaviour ?
                                  

    re .2
    
    I performed the upgrade using the direct load method, ie assign an ip
    address to the bridge module then use decndup to blast the firmware to
    the ip address assigned to the bridge.
    
    Mike K.

    
    Far and away the easiest way to get into this situation (I have no way
    of knowing if this applies to these particular cases, of course) is to
    be impatient.  The bridge takes a _LONG_ time to write the flash memory
    after the image is downloaded (and the image load itself can be very
    slow too under some network conditions).  If you power cycle the bridge
    when that flash write is in progress you _will_ corrupt the image and
    get a 'brain-dead' bridge.
    
    A good rule of thumb:  DON'T reset a device manually after a download
    until it has come all the way back up to normal operation by itself.
    

    
    	Is a "_LONG_" time in the order of 2 mins, 5 mins, 10 mins, an
    hour???
    
    	I've got 11 bridges (plus repeaters, mams) to upgrade and I don't
    want to get these screwed up.  It was a long enough wait just to get
    these.
    
    Scott

    re .5 & .6
    
    A long time is in the order of 3-5 minutes ( when you are waiting of
    course this seems like an eternity ! )
    
    I was able to successfully load the bridge via Bootp with the latest
    firmware image, patience is a virtue, and you do need access to a Bootp
    server to correct a corrupted firmware image.
    
    History Lesson
     
    The original problem was due to the customer loading the image,
    resetting the bridge before the image was written to flash, and
    compounded by the fact that the port the bridge uses to issue the Bootp
    request ( port 2) was defective (ie dropping bits, verified with a
    lan-analyzer). 
    
    I compounded the problem by upgrading a unit from spares, and did not wait
    the required time for the image to write to flash, hence another bridge
    with a corrupted image. 
    
    Moral of the story, read the release notes very carefully, and
    wait, wait, wait !!!!  Also, ensure you have a Bootp server available,
    and backups of the current firmware images, in the event ( this can
    happen to you ) of a corrupted image, or you will be very unhappy camper !!!
                                   
    Mike K.                   

    Hi Mike - I just got back to the office after being up in our
    ASO mfg plant since Monday. I got your phone message, and then
    checked in here. Looks like you got your answers to your problem.
    Scott is right when he says, be patient on the load process.
    The description in note 1193.1 is very accurate when describing
    the process to use when it has been determined that the bridge
    image got corrupted somehow either in the process of doing an
    upgrade or for whatever other possible reasons.
    you mentioned something about the bridge port used to do the load
    being bad or flakey. Could you elaborate on this a little more?
    
    Bob

    In my case I have the "port two" LED lighting yellow from time to time.
    This during the sequence of reinitializing and selftesting all the
    time.
    
    So, this bridge doesn't even sent bootp requests anymore. I think I
    came to a point of no return and I have field-service my bridge
    swapped for a new one allready loaded with V1.4.
    
    P.

    re .8
    
    I determined port 2 was defective on the bridge by monitoring the Bootp
    request packet with a lan-analyzer, the source and destination
    addresses in the packet header were corrupted, ie FF-FE-FF-FF-FE-FF
    instead of the ethernet broadcast address of all F's, 08-00-2A-
    XX-XX-XX instead of the digital assigned 08-00-2B-XX-XX-XX mac address,
    leading me to believe the aui interface was intermittently dropping bits.
     
    
    Mike K.