Conference netcad::hub_mgnt

    Just my 2 cents of experience on the DETMM problems.
    
    I just did an upgrade last night to a DETMM repeater running 1.0g code
    to 2.0 code. The TFTP server donwloaded the coad but when the module
    came time to reset all the leds on the module lit up and stayed on. The
    polling on the HUBloader screen just kept timing out every 15 seconds. 
    
    After waiting a reasonable amount of time (more than 10 minutes) I
    decided that the only thing I could do was power cycle it. I did this
    and the module rebooted ok and was running the V2.0 code. I really
    thought I had killed the module and breathed a sigh of relief when it
    came back (after hours upgrades when you are two hours from the
    nearest office are a real bugger). 
    
    
    regards
    
    Roger

    I was one of the original folks that found this problem, and I know
    that engineering *WAS* able to re-create it... but no fix was ever
    discussed. Problem was not tracked down.
    
    The only suggestion was to take the 'brain dead' module and power-cycle
    it. After a moment, it will send out a BOOTP request for "DETMM" to
    which ANY BOOTP server should be able to send it the image for
    DETMM200.BIN.
    
    (I never got this working, but this was the suggestion from LKG.)
    
    I simply had field service swap the module.
    
    Mark

    I tried to bring back to life my two dead modules as well and I
    could'nt get the Bootp side to work.
    
    Configuration was: tftp server configured to give the 900TM module an IP
    address and then I configured the TFTP server to serve of DETMM200.bin
    to anyone asking for DETMM.
    
    I then set up IRIS on another PC to watch what was happening.
    
    I could see the Bootp requests from the 900Tm but no response back from
    the hubloader PC.
    
    I tried another PC which has hubloader installed but still no luck.
    
    Both of these machines run fine doing firmware upgrade in the past
    (except for 900TM's :-)
    
    My only thought is that it's related to the fact that there is two
    different version of hubloader out there - one with the hubwatch kit
    and one with the netrider kit.
    
    Of course being able to bring a module back from the brink of death
    would be nice but does'nt stop the original problem of 1.0g modules not
    upgrading properly.
    
    The customer I am dealing with have there hubs in REMOTE sites
    connected via a large WAN network. We were planning do do the firmware
    upgrades over the LAN but with the possibility of the 900TM dying it's
    too big a chance to take.
    
    Hopefully some focus will be put on this and if I'm real lucky maybe
    someone from engineer will reply to this note. Come on, were not that
    bad a bunch to talk to are we ????
    
    Shaun
    

    
    Shaun,
    
    I have tried to get the braindead repeaters back on-line using a "real"
    computer (read alpha running unix) running as a tftp server and
    although I found the BOOTP request from the repeater and the subsequent
    response from the server to the repeater I never saw a TFTP request
    from the repeater.
    
    All that happened was that the repeater kept sending BOOTP requests.
    
    I have found thru testing of live V1.0g modules that if they are
    upgraded to V1.1 first and then to V2.0 then all is well.
    
    I proceeded to site to try this method in a critical hub900 and found
    this additional step to resolve the killing of 900TM modules.
    
    This was carried out while attached to the HUB900 being upgraded and
    will now be tested over the WAN link by the customer using the
    DETMM110.BIN file I got off the 'net.
    
    Prior to doing this step the customer upgraded 10 modules at one site
    and got 3 braindead modules which all happened to be V1.0g so it was
    with some trepidation that they attempted the same thing with 8
    repeaters at another site, 5 of which were V1.0g .
    
    We upgraded according to the additional V1.1 step and all modules
    upgraded with no problems.
    
    I put this forward as a possible workaround to cut down the number of
    spares we are using in this upgrade process.
    
    John Moretti
    RSSG Brisbane

    re: -.1
    
    Thanks a million... I think engineering would love to hear this. Many
    of us have had this bug bite us, but no one was able to track it down
    as thouroughly as you did.
    
    (Did you forward to some of the folks in LKG?)
    
    Thanks,
    
    Mark

Hi John - I have been keeping an eye on this problem and am pleased to
          hear about upgrading to v1.1 prior to going to v2.0.

	  Thanks for your help.

Frank.


[Posted by WWW Notes gateway]

    
    
    
    
    Hello all,
    
    I think, there are two Bugs in the upgrade Process of the DETMM:
    
    Situation:
    ----------
    I had the same Problem at a big Customer Site, during
    the upgrade of the DETMM from Versions V1.0F (Manufactory
    Version ?) and Versions V1.0G to Version V2.0.0
    The Customer produced about 4 braindead Moduls out of 10 Modules.
    So he sent me 2 of these Modules to "repair" them.
    (the others went already to the Repair Center)
    
    
    Problem 1 (or Bug):
    -------------------
    I put it in to our Test HUB, connected the MGNT Station direct on
    one of the 32 Ports.  (PC, Windows, Hubwatch 4.1.2)
    The Netrider Loader has the Version:1.0-03
    
    I made the following Entry in the Netrider Loader:
    In Config: -Servers:  -the Ethernet Address and the IP Address
               -Files:    -the Request File Name: DETMM
                          -the Local File Name: DETMM200.BIN
                           (Read Access)
              
    Then i setup IRIS and we could see the Bootp requests. Also in the
    Netrider Loader Window, we could see, how the Counter for BOOTP goes
    up, but it never starts to load with the TFTP Server!
    So, i think, it is not possible to load a braindead DETMM with
    the Netrider Loader supplied with Hubwatch!
    
    Workaround: I setup in UCX BOOTP and a TFTP Server and it just
    ----------  works fine. Its incredible fast, as soon as you have
    	        finished to set it up, the braindead Module is loaded
    		and running again!
    
    Problem 2 (or Bug)
    -----------------
    I asked the Customer about the Version of the Hubloader,
    he told me that he is using Version V1.0.0
    I checked and found out, that these Version is supplied with
    Hubwatch V4.0
    In our Equipment we are using Hubwatch Version V4.1.2 with
    Hubloader V1.1.0
    Now i downgraded the same Module in our Hub to Version V1.0G
    with Hubloader and made the Upgrade direct to Version V2.0.0
    without any Problems! Even i made it several Times, but never
    had any Problems!
    Now i really tried to shut the Module braindead: In several
    stages of the download Process i took the Module out of
    the Hub, but it n e v e r got braindead. If I pulled to early,
    than it kept the old Version, and any stage later, it had
    already the New Image loaded!
    So for me, i think these must be a Bug of the Hubloader Version
    V1.0.0!
    The Entry 3379.4 seems to be the Workaround for Hubloader Version
    V1.0.0?
    
    Any Comments to these 2 Problems are verry appreciated,
    
    Thanks,                                       
    
    Daniel MCS Switzerland