Conference 7.286::fddi

    >>Does FDX mode need to be enabled on an FDDI controller before it will
    >>attempt to negotiate an FDX connection? I realize that the switching is
    >>automatic - I'm wanting to know if feature has to be first enabled. I
    >>thought I read that the  Gigaswitch does this for you, however what if
    >>I want to connect two FDDI nodes  directly (point-to-point, no
    >>concentrator). 
    
    There is an SNMP MIB object called eFDXEnable which must be TRUE for
    the FDDI node to start negotiating an FDX connection.  On the DEFEA and
    DEFPA adapters, we've set this to FALSE by default in the firmware and
    force users to enable it (via command line switches in drivers, or
    SNMP) before we start the negotiation process.  The reasons were many,
    but it boiled down to FDX being an *optional* feature and most of the
    drivers written for those adapters had the ability to enable/disable
    this option.  Note: In a similar fashion, we disabled ring purger on
    the FDDI adapters by default.
    
    On the DEFTA, DEFAA, DEFQA, etc, I'm pretty certain that we enabled
    eFDXEnable by default in the firmware because the only OS's supported
    (OSF/1, Ultrix, and/or OpenVMS) did not have driver command-line
    switches that could easily enable this feature.  This is slowly
    changing and the OpenVMS and OSF/1 drivers for DEFEA and DEFPA should
    (will?) have options for users to select/deselect this feature.
              
    I don't know if there's an option under OpenVMS or OSF/1 to see if the
    node is in FDX mode.
    
       - Larry

<I used PNV SNMP MIB Browser using dec-elan-v27.mib to look at eFDXstate
<however it returned the error - "The variable does not exist or is read only".
<Should this have worked to a DEFTA using an SNMP community name of public?

PNV returns "The variable does not exist or is read only" whenever I to do an 
SNMP GET to a DEFTA using the following MIB objects
eFDXOp    (.1.3.6.1.4.1.36.2.18.1.1.4.1.1.4) or
eFDXstate (.1.3.6.1.4.1.36.2.18.1.1.4.1.1.5)

Should this work? I can get all the standard MIB objects such as system, 
interfaces etc - just not the dec-elan extensions.

Geoff..

>>Should this work? I can get all the standard MIB objects such as system, 
>>interfaces etc - just not the dec-elan extensions.
    
    The DEC Extended MIB objects are supported in the firmware on the
    DEFTA, but I'm sure it requires at least some support in the driver and
    OS to provide those objects to the SNMP agent.
    
    Try sending mail to Rajul Shah (WASTED::RAJUL).  He wrote/maintains the
    FDDI drivers for OSF/1 and may be able to shed some light on how well
    the MIB objects are supported in that environment.
    
    /l

        I believe that:
    
    fddi_config -i fta0 -d
    
        ...will return the current information (from OSF1) about a DEFTA,
    although I don't have access to an OSF1 system to check it.
    
    

# fddi_config -i fta0 -d

fta0 ANSI FDDI settable parameters

Token Request Time:                7.9872 ms
Valid Transmission Time:           2.6214 ms
LEM Threshold:                     8
Restricted Token Timeout:          1000.0000 ms
Ring Purger State:                 Purger off

fta0 Full Duplex Mode: Enabled
Full Duplex State:                 Operational

fta0 Counter Update Interval: 1 sec



Works fine on 3000 m900


Now how do I get this information under VMS?
I will be runing TCPware and DECnet/OSI.


regards,
gene

    Can anyone supply the info from .5 on an OpenVMS system please ?.
    
    Thanks,
    	Steve.

    Hello,
    
    Looks line LANCP under OpenVMS V6.2 will include a command to do this,
    LANCP> SET DEVICE/FULL_DUPLEX, but I can't get it to work with my DEFPA
    here locally.
    
    I'll post any new findings in my base note, 1647.*.
    
    Good Day,                 
    John Sobecki, CSC/Colorado

The command would be
  $ mc lancp set dev dev-name/full_duplex

And to see the current state
  $ mc lancp show dev dev-name/param