On Sat, 1 Jun 2002 14:16:00 -0700 "Beaker" <beaker@myrealbox.com> wrote:

> Can anyone suggest a simple serial terminal emulation scheme for
> connecting from NetBSD/i386 to NetBSD/Sparc via a null-modem cable?
> Basically what I want is this:
> 
> TCP/IP functionality
> SSH
> Connectivity via serial port

Beaker, 

For starters, try "cu" this way: 

	cu -9600 --parity=none -l /dev/tty00 dir

If you hook up the cable, start cu, and power on the sparc, you should see
console output.  Your adapter will do for that purpose.  

To get ip going, you need pppd.  SSH will ride along with everything else
atop TCP, IP, and PPP, in that order.  For good PPP, you need a true
crossover cable, unless you want to do some serious putzing with pppd's
setup (on both sides, of course).    

I've reduced your comparison to the modem control signals and labeled
them, placing the DTE signals on the left, so we can see what's what:

Your adapter          Primer spec
-------------------   -------------------
RTS + CTS -----  CD   RTS ----- CTS
      DTR ----- DSR   DTR ----- DSR +  CD

What I think is going to cause you grief is CTS.  RS232 says that Data
Terminal Equipment (DTE, your computer) raises RTS to indicate it's ready
to receive, and looks for raised CTS from the DCE (Data Communications
Equipment, your emulated modem) to indicate that the DCE is ready to
receive.  No CTS from the modem, no send to the modem.  

The primer places RTS opposite CTS for that reason.  When the sparc raises
RTS to indicate it's ready to listen, your i386 sees CTS and thinks "OK,
the modem's ready to rumble, here goes", and starts transmitting.  When
the sparc gets bored or tired or is otherwise unready to listen further,
it drops RTS.  The i386 sees CTS disappear and shuts up.  Thus on 5 volts
doth flow control rest.  

DTR belongs opposite DSR by the same logic.  These signals indicate the
presence of connected, powered-on equipment.  The DTE raises Data Terminal
Ready and the DCE raises Data Set Ready.  They're not used for flow
control.  

Carrier Detect (CD) is a secondary statement of readiness from the modem. 
In a null-modem environment, there's no such thing as lost carrier, so the
primer places it opposite DTR, too.  

So, if your sparc is on and connected per the primer's spec, your i386
sees a modem (DSR) that's online (CD), and listening (CTS).  Should the
sparc become otherwise occupied, it can drop RTS.  The i386 will see CTS
go away, and stop sending.  

With your adapter, your i386 will see the same three signals, but for
different reasons.  Because CTS is looped back onto RTS, the sparc can't
drop it by dropping RTS.  If the sparc drops RTS, all that will happen is
that the *sparc* will see its own CTS go away -- not exactly a good way to
communicate anything to the other side.  

The good news is that it might not matter and it won't matter if it does
matter.  Your sparc and i386 are both pretty quick relative to the line
speed.  They might neither ever need to drop RTS, and even if they do (and
are disregarded, oh well) TCP will notice the dropped packets and resend
them.  I'd guess as long as your CPU is <80% busy, flow control won't
enter into the equation.  

Wow.  Whoever thought we'd still need to think about brain-dead RS232 in
this day and age?  I made my own crossover cable back when 512 KB RAM was
king and a nice 8088 cost $2600.  Everything else has been replaced many
times over, but there it sits connecting my 8088 cum 80386SX cum 80486 cum
PII to my Sparcstation.  Nothing like a voltage to send a bit, I guess.  

Regards, 

--jkl