Conference netcad::hub_mgnt

>1. Is the DECserver 90TL supported for this configuration ? I have one
>   but I can't get it to show up on either HUBwatch or the aggent.

    Not for V1.0 of agent and HW.
    


    
>2. Is there some way to remotly via SNMP configure SNMP trap destination
>   and community string ?
    
    Traps are not supported in v1.0.  Look to the next major release for
    trap support.
    



>3. Some times when I try to do a SNMP set from HUBwatch i get the following
>   error message:
>
>	An SNMP error was returned from the agent.
>	This could occur if the WorkGroup bridge is unreachable, or if there
>	was a MAC address mismatch when added to the slot Table, or if the
>	module is not really present in this slot.
>
>   I know for fact that this isn't the case. I this a known behaviour ?

    Sometimes the agent isn't able to perform the proxy function (lack of
    internal buffers, target object not being reachable, target currently
    being managed by another user, etc).  The success of the proxy request
    (ie, the SET or GET) is device-dependant for the most part, and
    network-dependant from time-to-time.  For example, if a POTS unit is
    being managed by another agent, then it's MOP console port is locked
    (by a single user), and cannot be a target of another agent's proxy
    request until the console is released.  A proxy request to a repeater
    depends on the WGB being reachable (in the up/forwarding state,
    non-blocking, non-learning).  You could also be seeing timeouts and retries
    occurring.
    
    As a help, I've designed-in some debugging printf statements that may
    be useful.  Under Ultrix, enable these by defining the environment variable 
    DH90_DEBUG_SNMP.  Ie,
    
    csh> setenv DH90_DEBUG_SNMP
    
    Then, invoke HUBwatch for Ultrix from __THIS_PROCESS__ (the one that
    has the env var defined) or a __CHILD_OF_THIS_PROCESS__ (Ultrix child
    processes inherit env vars from their parents).  This means, that if
    you run HW from the MSU or MCC maps, then the map (the parent) must be
    run _AFTER_ this env var is set, and from the process that has it.
    When it forks (runs) HW (the child), the printf's will appear in the 
    window that invoked the parent/child.
    
    Or, just run HW standalone, after defining the env var:
    
    csh> $NMS_DIR/bin/DH90_main -x (ip_address) -c (community_string)
    
       (use appropriate values for (ip_address) and (community_string)
        symbols, above.  Also, ensure the the env var NMS_DIR is properly
        defined.)
    
    What you will see is the dialog between HW and the agent.  If you know
    SNMP, and have all the MIB's handy (they're posted in this notes file),
    then you're all set to report the problem.  Post your "snmp dumps" 
    to this notes file if you're really having problems.

        (hint: you can do a "typescript" in Ultrix, or use the DECterm
         cut/paste to save the output printf's.)
    
    


>4. Today with the current version of DECmcc I can't see any way of having
>   multiple DEChub icons on the map that is controlled by the same agent, 
>   correct ? 
    
    I believe you are correct.

>   But is this going to be possible with V1.3 and the proxy
>   SNMP pseudo-register function ?

    I am not knowledgeable in MCC internals/functionality.  (Perhaps Robin could
    shed some light on this).



5. If 4 is true will it then be possible to launch HUBwatch so it pick
   up the selected DEChub ?

    (I defer to those who know MCC).
    

6. Today the HUBwatch for MSU seems to be designed to work with MSU V1.1.
   When could we excpect a version for MSU V1.2 ?

    This is not difficult.  We did it for Interop.  I'll try to get the 1.2
    updated menubar code for this.  That should be all that is required.



7. The DEChub copyright window that pops up at start time, is it possible
   to supress it, or remove the CANCEL button ? I have already many times
   pressed the Cancel button by misstake ! Normaly you press cancel to
   close a window, not the application !

    This would require a code change.  BTW, this message (like the one at
    the startup of MSU) will disappear automatically, if you let it go for
    a few seconds ...



>8. The switch button used to enable and disable a port some times get
>   corrupted. Usualy I run HUBwatch on the risc and displayed on a VAX.
>   Have this been observed before ?

    Please explain "corrupted".  Bad stuff in the pixmap (drawing switch)
    area?  Bad function?  I would like to know more details.



Regards Stefan

>P.S. The HUBwatch interface is real nice. I had some customers here today
>     and they liked it !

    (The team appreciates your support!)



    
>D.S. A note some where in this conference documenting the location of all
>     software for the DEChub should had saved me hours geting it to work.


    I will post a note soon when I can get some permanent location
    pointers.


	Regards,

	.bl

    I'm having problems similar to those described in 0. item number 3.
    
    >	An SNMP error was returned from the agent.
    >	This could occur if the WorkGroup bridge is unreachable, or if there
    >	was a MAC address mismatch when added to the slot Table, or if the
    >	module is not really present in this slot.
    
    This occurs when I attempt to use a different community name for 
    read-only and read-write.  I tried "public" for read-only and "private"
    for read-write and get the error.  I have correctly set these in the
    agent and they show up as such in the Community/Manage Table screen.
    If I use "public" for both read-only and read-write everything works
    OK.
    
    I put a protocol analyzer on the line and HUBwatch is sending out
    "public" for the read-write request even though it is set to
    "private" in the DH90_agents file.  Below is my DH90_agents file:
    
    #############################################################################
    # The format of this file is:
    # <IP_address> <IP_name>             <RW Community> <timeout> <retries>
    #############################################################################
    #
    16.123.96.51 dechub.mlo.dec.com public 5 1
    16.67.32.238 netran.dco.dec.com private 5 1
    

Okey I Have reproduced problem 3 & 8 from .0


>3. Some times when I try to do a SNMP set from HUBwatch i get the following
>   error message:
>
>	An SNMP error was returned from the agent.
>	This could occur if the WorkGroup bridge is unreachable, or if there
>	was a MAC address mismatch when added to the slot Table, or if the
>	module is not really present in this slot.
>
>   I know for fact that this isn't the case. I this a known behaviour ?
>
>8. The switch button used to enable and disable a port some times get
>   corrupted. Usualy I run HUBwatch on the risc and displayed on a VAX.
>   Have this been observed before ?

Both problem seems to occure when the "Autoscan" is enabled. 

The "switch" button I refered to is the port admin. The problem reported is that
the field with the arrow switch becomes coruppted.

/Stefan

Rep .1

>>1. Is the DECserver 90TL supported for this configuration ? I have one
>>   but I can't get it to show up on either HUBwatch or the aggent.
>
>    Not for V1.0 of agent and HW.

Hi, Is there any version of agent and HW with support for the DECserver90 TL 
ready yet ?

Next week we are planing to show the DEChub and HUBwatch software on a big
UNIX fair here in Sweden. Therefore it would be nice to show the Telnet server,
not just in the hub, but also in HW software.

/Stefan

    The 90TL needs to support SETs before anything will work.  This has now
    happened.  V 1.1 of HUBwatch will support the 90TL.  Seeds are planned
    for mid_December with release in January.