1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Serial port access to console

Discussion in 'Sun Hardware' started by Vikas Agnihotri, Sep 21, 2003.

  1. I am trying to access the console on my Sun Fire 880 server via the serial
    port on the back plane.

    Here is what I did

    Connected a RS232 male DB25-female DB9 cable to the Serial A/B port on the
    backplane

    Connected the other end (female DB9) to the serial port on a Windows 2000
    workstation

    Started up Programs/Accesories/Comm./HyperTerminal

    Created a new connection using COM1 with default settings 9600 8N1 (9600
    baud, 8-bit, No parity, 1 stop bit)

    Powered up the Fire 880

    Nothing!

    The Hyperterminal session shows connected, but I dont see anything in the
    window.

    What am I doing wrong?

    Should I be using some other terminal/comm software rather than
    HyperTerminal?

    I have a null-modem adapter (female DB9 - male DB9). I tried to use this
    but the female DB9 end of the adapter doesnt fit into male DB9 COM1/serial
    port on the PC. The connectors are the same size, so one doesnt slide into
    the other. Does this matter? Do I need the null-modem?

    Help? Thanks
     
    Vikas Agnihotri, Sep 21, 2003
    #1
    1. Advertisements

  2. Are you using a NULL MODEM (reverse) cable ?.
     
    Chris Newport, Sep 21, 2003
    #2
    1. Advertisements

  3. Vikas Agnihotri

    Greg Andrews Guest

    This is very likely not a null-modem cable. It may have the right
    connectors at each end, but if the wiring in the middle doesn't
    connect things properly, it still won't work.

    And even then, the machine could be configured to have its console
    on the RSC card instead of the A/B port.

    -Greg
     
    Greg Andrews, Sep 21, 2003
    #3
  4. Vikas Agnihotri

    Eddie Guest

    Greg is right (about both the cable and the RSC/serial thing).
    When you have solved both thing it could be you have a keyboard attached (I
    know real sysadmins don't do that to a server, but you don't want to know at
    how many 'professional' companies I saw this!)....when a keyboard is
    detected, eeprom's "output-device" is automatically set to keyboard instead
    of ttya!

    Regards,
    Eddie
     
    Eddie, Sep 22, 2003
    #4
  5. Vikas Agnihotri

    Huge Guest

    Please do not top-post.

    Can I enquire as to exactly how one sends output to a keyboard?
     
    Huge, Sep 22, 2003
    #5
  6. Vikas Agnihotri

    Andrew Tyson Guest

    further to all of the other advice you may want to edit /dev/default/kbd
    on the V880 and uncomment the following line;

    # Uncomment the following line to disable keyboard or serial device
    # abort sequences:
    #KEYBOARD_ABORT=disable

    otherwise if you remove the laptop/null modem cable the V880 will receive
    an interrupt and drop to the OBP prompt (which is probably not what you
    want).

    Andrew
     
    Andrew Tyson, Sep 23, 2003
    #6
  7. And run 'kbd -i' after changing /etc/default/kbd?

    On a related note (dropping to OBP prompt), how do professionals or large
    datacenters do this?

    I have read that most professional, experienced sysadmins prefer to keep
    all their servers 'headless' and access the console thru either serial port
    or RSC or 'tip' (tip seems very archaic?).

    That being the case, KEYBOARD_ABORT would _have_ to be set to 'disable',
    right? I mean, you wouldnt want the system pausing at the OBP prompt
    everytime you plugged in a serial port laptop/null-mode and wait for you to
    type 'go', right?

    In general, what is the state of the art, recommended way for Sun console
    access?

    Comments? Thanks
     
    Vikas Agnihotri, Sep 23, 2003
    #7
  8. Vikas Agnihotri

    Lon Stowell Guest

    Approximately 9/22/03 16:37, Vikas Agnihotri uttered for posterity:
    Set the keyboard to the alternate break sequence and leave
    abort disabled. That way you can drop the system to the
    OK prompt if all else fails.
     
    Lon Stowell, Sep 23, 2003
    #8
  9. Vikas Agnihotri

    Greg Andrews Guest

    For modern machines like the V880, set the KEYBOARD_ABORT to "alternate"
    rather than "disable". That will prevent accidental break signals from
    halting your sparc server, while still allowing your system admins to
    halt the server when they want to. The "alternate" abort sequence is
    the three characters Enter, Tilde (~), Control-B.

    -Greg
     
    Greg Andrews, Sep 23, 2003
    #9
  10. Vikas Agnihotri

    Greg Andrews Guest

    That's not possible, Lon. There aren't two parameters that can be
    set to the Alternate and Disabled values, as you described.
    The abort setting is just one parameter with three possible values:
    Enabled, Disabled, or Alternate.

    -Greg
     
    Greg Andrews, Sep 23, 2003
    #10
  11. Um..how do I enter this sequence? Press Enter i.e. start a new line and
    then enter ~ and Ctrl-B as 2 separate keys?

    Also, it seems quite limiting for a modern system like the V880 to require
    a reboot to change the console i/o device? When I unplug the local USB
    keyboard in its backplane, the console says 'USB keyboard not responding.
    Please power cycle'. This seems extreme. Even a accidental break signal can
    be recovered from (usually) by typing 'go' at the OBP prompt. If someone
    accidentally unplugs the USB keyboard, the system has to be power-
    cycled?!!!

    I thought that the 'kbd -r' command would be relevant here since the man
    page says that 'reset the keyboard as if at power-on'. But it doesnt seem
    to do anything noticeable on a running system. I thought that if I did
    something like 'sleep 20 && kbd -r', and quickly swap between a local
    keyboard and ttya, by the time the 'kbd -r' was run, it would again 'seek'
    the keyboard connector like it does at power-on and change the input-
    device.

    Comments? Thanks
     
    Vikas Agnihotri, Sep 23, 2003
    #11
  12. Vikas Agnihotri

    Leach Guest

    We use terminal servers, and set the keyboard abort to alternate
    (to prevent misunderstandings if the terminal server gets power
    cycled.) The terminal servers use Securid to restrict access.
    The consoles are wired with Cat5 (or better likely these days)
    and patched just like any other network device. They only run
    at 9600 baud, so the wire lengths can be quite long in practice.

    The system is secure, dead simple, and works on all the
    generations of Sun gear that we have. It also prevents
    many drives to the computer room, or in some cases,
    overseas flights.

    In the computer rooms themselves, we keep trolleys of Wyse terminals,
    and wheel them around in emergencies. Nothing beats having
    a real terminal when bringing your network up from scratch.
     
    Leach, Sep 23, 2003
    #12
  13. Vikas Agnihotri

    Greg Andrews Guest

    Press Enter, then press Tilde, then press Ctrl-B. One keystroke
    after the other.
    The console device is selected at boot time by the Open Boot Prom,
    before the Solaris kernel is running. That's why the boot device
    works at the "ok" prompt when the kernel isn't running.

    So to change it, you need to go back to the OBP. That requires a
    clean shutdown if you don't want corrupted filesystems.


    Most people who are going to use the serial console plan ahead and
    use the serial console as soon as they take the machine out of the box.
    They don't connect a keyboard and monitor, so they don't have to change
    the console device.

    -Greg
     
    Greg Andrews, Sep 23, 2003
    #13
  14. Vikas Agnihotri

    george Guest

    Not familiar with this server , but mostl of the time you need a SERIAL
    PRINER CABLE, which is a null modem cable. Can be bought from any computer
    store, 25 ping male to 9 pin female

    GEorge
     
    george, Sep 23, 2003
    #14
  15. I used special cables which did NOT cause a break signal.
    Connect all machines to a DiGi console server and use the alternate break
    sequence.

    /wfr
    Fredrik
     
    Fredrik Lundholm, Sep 23, 2003
    #15
  16. I doubt cables ever "cause" or prevent break signals. It's the hardware
    at the other end. I don't see how you could construct a cable to change
    that and still allow communications to take place.
     
    Darren Dunham, Sep 23, 2003
    #16
  17. I doubt cables ever "cause" or prevent break signals. It's the hardware
    at the other end. I don't see how you could construct a cable to change
    that and still allow communications to take place.[/QUOTE]

    Well, actually I used special DB25->RJ45-connectors,
    mounted on each server, wired to not cause a break signal when the
    Rj-45 cable (attached to a VT-terminal) was moved between machines.

    /wfr
    Fredrik
     
    Fredrik Lundholm, Sep 23, 2003
    #17
  18. How is this wiring special?

    I've never unintentionally dropped a machine by moving a serial cable
    between powered-on equipment or leaving it disconnected. I've only done
    it by doing something on the equipment (powering off or resetting), or
    by plugging a cable into a powered off box.

    The break signal is sent on the Rx line (or the Tx line, I'm never sure
    which perspective it's from). You can't disconnect it and have a
    working cable, so if the box at the other end wants to be stupid, it's
    going to send the break. Are you doing something different to that line
    than a normal connection?
     
    Darren Dunham, Sep 23, 2003
    #18
  19. Well, there were more wires than rx/tx involved.
    It might be that the RJ45 was better in the sense that
    plugging/unplugging was smother and caused fewer glitches.

    The VT was fed from the UPS and never went down.

    /wfr
    Fredrik
     
    Fredrik Lundholm, Sep 23, 2003
    #19
  20. Vikas Agnihotri

    Greg Andrews Guest

    If you unplug the cable from the terminal (or terminal/console server),
    the cable inductance and inter-wire capacitance can combine with the
    terminal's output voltage to create a voltage spike. Especially when
    the cable is longer than it should be, doesn't have the right kind of
    insulation around the wires, or is too near transformers or other
    sources of electrical noise. A glitch induced this way tends to be
    very weak, though.

    The load resistor described as the "Soldering Iron Solution" in
    http://www.cisco.com/warp/public/770/fn-tsbreak.html can suppress
    this kind of weak glitch. I've personally had machines halt merely
    because I unplugged or plugged the serial console cable. Perhaps
    that's the kind of cable Frederik is talking about?

    The problem with the resistor is exactly what you said - it can only
    suppress weak glitches due to cable capacitance/inductance. It can't
    suppress strong glitches that are driven by the output circuitry on a
    terminal or terminal/console server. Strong glitches account for the
    largest percentage of unintended break signals, so the "Soldering Iron"
    method usually doesn't help.

    I don't know how the NUD4273 device works, but I would guess it allows
    short pulses through and suppresses long ones. It's expensive enough
    that it could have some clever digital circuit in there to detect a
    long enough pulse on the input and force the output to the idle state.

    -Greg
     
    Greg Andrews, Sep 25, 2003
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.