Conference netcad::hub_mgnt

    Sounds like MAM on being upgraded lost its IP address <this
    is normal>
    I would assume all you have to do is add it via console, and
    you won't see the display indicating "Sending BOOTP Request"
    anymore.
    
    Bob

	Thanks a quick reply.
	
>    Sounds like MAM on being upgraded lost its IP address <this
>    is normal>

	You talk about that the MAM lose all setting(IP address,community
	name and so on) after firmware upgraded ?
	
	If so, exactry it's a <NORMAL> way as you mentioned.
	
	But MAM should complete its powerup self test and start operation
	with factory default, even if the all setup of MAM was lost.
	
	I had upgraded 20 DEChub900 MS's firmware upto V3.0.0,
	but the only one HUB MS encountered this problem.
	The other HUB MSs restarts automatically with the factory default
	after the firmware is successfully downloaded.
	
>    I would assume all you have to do is add it via console, and
>    you won't see the display indicating "Sending BOOTP Request"
>    anymore.
    
	I have no response from console (setup) port while MAM diplaies
	"Sending BOOTP Request".
		
>    Bob

	Any other opinions are also appreciated.
	
	Regards,
	
	Takaichi.

    Hi Takaichi,
    
    Did you load this hub through tftp (using bootp) or was this an
    NDUplus load of the MAM ?
    We (systems test) did have a hub with a bad MAM (Hardware problem) that 
    is exactly the same as you described. This MAM is presently being
    looked at by the hardware development group. This hub would never come
    out of bootp request (with no jumpers on the mam) 
    We could not use this hub again till we swapped the MAM module.
    
    						Tim
    
    

My customer had finally gotten his 3 DEChub900, and I was onsite to upgrade
to V3.0. We upgraded all three using NDU+ on VMS, and one of the hubs never
recovered. It was stuck without passing selftest, with the message :
"Sending BOOTP Request". Now as it happened, a defect power bus may be the
cause in this particular case. This HUB was supposed to be configured with
two power supplies. One power was DOA, the other was working fine. We ordered
a new power, and when inserted it blew up. It looks like the upper right hand
power slot was somehow shorted. This may have affected the download of the
new firmware, but I am just guessing. I had to order a new power, HUB backplane
and new MAM.

RE .1 : When the MAM is in this mode you can't get into console mode, it is
        completely lost (at least as far as I know).

	Tor

    
    re:.3,.4
    
    Could be that these are related. We (System Test) did have a power
    supply with an upside down connector take out a hub's power slot.
    Could be that Tim's MAM was present in that hub at the time the
    supply was inserted. 
    
    Bob

    
    re:.2
    
    Takaichi,
    
    	One thing which you could try to recover your MAM is to do a
        "primitive load". To do this setup a SLIP line to your MAM's 
        OBM port with address w.x.y.z (your favorite IP address).
        Then perform a tftp push of the MAM image file from some
        tftp capable system. For example on ULTRIX:
    
        tftp -p mam.bin w.x.y.z mam -image
    
        The SLIP line is setup as you would in order to perform out of band
        management, but you do not (cannot not) set an IP address on the
        MAM itself. The SLIP line should be set at 38400 baud as this is what 
        the MAM will expect.
    
        If all is well you will see the MAM LCD begin to display an
        incrementing block count. Also, you'd want to perform a ping
        prior to the tftp to make sure all is well. 
    
        We have seen a case in which the MAM will cycle back to the bootp
        request after the image is downloaded. This is being investigated
        by the hardware folks as Tim reports.
    
    Hope this helps save your MAM,
    Bob

    
    If the mam displays 'Sending Bootp...' rather than booting, it has
    detected that the Flash image is invalid; you must have had either bad
    power or an interruption of some kind during the Flash write.
    
    It is running the primitive loader; you can send it an image as
    described in the previous note (I don't think it responds to 'ping',
    though).  It will accept any IP address in this mode (since it's SLIP
    it just assumes that whoever is on the other end of the wire knows best
    :-)
    
    Or you could replace the MAM...
    

    RE: .0, .2 
    My apologies for mis-understanding your comments. When I saw 
    in the base note words to the affect that it was "ok" I interpreted
    this that you were saying everything loaded ok. Thus I went on
    to say that losing IP address on a successful upgrade is normal.
    I obviously didn't understand that you were really saying that
    your MAM was dead <as in not responding nornmally>.
    
    Bob

	Thanks all and sorry for my late response.
	I didn't back to the office at last week.
	
	I used DECndu Plus for DOS to download the firmware.
		
	I don't know whether DECndu Plus for DOS supports SLIP or not.
	
>              -< Ahhh brain dead as in doing primitive-load..... >-
>
>    RE: .0, .2 
>    My apologies for mis-understanding your comments. When I saw 
>    in the base note words to the affect that it was "ok" I interpreted
>    this that you were saying everything loaded ok. 

	Sorry in short explanation and confuse you.
	
	Anyway, I see that "Sending BOOTP Request" message means
	missing wite the image to Flash memory on the MAM and 
	that is a brain dead MAM.
	
	Takaichi,