stupid Ultra 10 serial port question

Hi,

I've been attempting to get a PPP connection between two
boxes using a null modem cable (with the 4-1&6 1&6-4
etc).
The connection works between my no-name uplcom(4) and com(4)
of a Dell.  However when I connect that to serial port B
on an Ultra 10 things don't work.

One obvious difference is that with no cable connected the 
Ultra 10 will start sending stuff immediately.  The OptiPlex
will wait for a carrier, CTS, DSR, DTR, or something before
doing anything.

Another thing is that with the cable connected starting pppd
on the Sun followed by the Dell will cause a hangup on both
of them.

When I start pppd on the Dell first, pppd on the Sun won't
send anything until I terminate pppd on the Dell.

But it's really baffling because tip and cu work fine.

This problem is annoying, but it's not important if it will
work fine with a real modem.  I don't currently have an ISP

or two phone lines to test with.  Does anyone successfully
use a dial-up/in modem on an Ultra 5 or 10?

	Jonathan Kollasch

> I've been attempting to get a PPP connection between
two boxes using
> a null modem cable (with the 4-1&6 1&6-4 etc). 


Unless this is a mockup of a dialup connection, my
experience suggests
that you would be better off using SLIP instead of PPP.  I
once spent
most of an afternoon trying to configure two boxes to get
packets over
a hardwired serial line with PPP and was unable to get
something that
came back up for all sequences of reboots and line
disconnects and
reconnects.  Then I switched to SLIP and it all Just Worked
- SLIP is
too simple for there to be anything to break, approximately.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouserodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3
27 4B

On Mon, Apr 17, 2006 at 12:40:18PM -0400, der Mouse wrote:
> > I've been attempting to get a PPP connection
between two boxes using
> > a null modem cable (with the 4-1&6 1&6-4
etc).  
> 
> Unless this is a mockup of a dialup connection, my
experience suggests
> that you would be better off using SLIP instead of PPP.
 I once spent

Ultimately this is supposed to be a dial-in server.  Besides
it's
inability to handle native IPv6, SLIP's 296 octet MTU even
precludes
IPv6 tunneling (unless it fragments or something
automatically).

> most of an afternoon trying to configure two boxes to
get packets over
> a hardwired serial line with PPP and was unable to get
something that
> came back up for all sequences of reboots and line
disconnects and

Not Important Now.

> reconnects.  Then I switched to SLIP and it all Just
Worked - SLIP is
> too simple for there to be anything to break,
approximately.

I tried using the -h flag to slattach on both boxes.  Again,
it works
between the Dell and uplcom, but not the Dell and Sun.  In
fact the
Sun complains: "sl0: no carrier and not local". 
However it does work
with the -l flag.

My suspicion is that Sun wired the port wrong, or that
sabtty(4)
has some bugs.

The only remotely related thing to this in the past was:
http://mail-index.netbsd.org/port-sparc64/2003/08/
02/0004.html

I tried connecting to a modem pool, it acts the same on both
the
Dell and Sun (like in the above message),  but the hangup is
probably caused by my invalid username/password I think.

I noticed in sys/arch/sparc64/dev/sab82532reg.h:

#define SAB_CCR4_ICD    0x10    /* invert polarity of
carrier detect */

but it is not used in sab.c.  I might try adding that bit to
SAB_CCR4
in sabtty_reset().  Also, I'll try connecting between two
my two
Ultra boxes.

	Jonathan Kollasch

On Mon, Apr 17, 2006 at 12:55:53PM -0500, Jonathan A.
Kollasch wrote:
> I noticed in sys/arch/sparc64/dev/sab82532reg.h:
> 
> #define SAB_CCR4_ICD    0x10    /* invert polarity of
carrier detect */
> 
> but it is not used in sab.c.  I might try adding that
bit to SAB_CCR4
> in sabtty_reset().  Also, I'll try connecting between
two my two
> Ultra boxes.

Ok, the two Sun boxes both have carrier problem errors, but
I almost
expected as much.

So, I tried a modified kernel:

--- sys/arch/sparc64/dev/sab.c.orig     2006-03-28
11:38:27.000000000 -0600
+++ sys/arch/sparc64/dev/sab.c  2006-04-17
13:19:09.000000000 -0500
 -1109,7
+1109,7 
        SAB_WRITE(sc, SAB_CCR1, SAB_CCR1_ODS | SAB_CCR1_BCR
| SAB_CCR1_CM_7);
        SAB_WRITE(sc, SAB_CCR2, SAB_CCR2_BDF | SAB_CCR2_SSEL
| SAB_CCR2_TOE);
        SAB_WRITE(sc, SAB_CCR3, 0);
-       SAB_WRITE(sc, SAB_CCR4, SAB_CCR4_MCK4 |
SAB_CCR4_EBRG);
+       SAB_WRITE(sc, SAB_CCR4, SAB_CCR4_MCK4 |
SAB_CCR4_EBRG | SAB_CCR4_ICD);
        SAB_WRITE(sc, SAB_MODE, SAB_MODE_RTS | SAB_MODE_FCTS
| SAB_MODE_RAC);
        SAB_WRITE(sc, SAB_RFC,
            SAB_RFC_DPS | SAB_RFC_RFDF |
SAB_RFC_RFTH_32CHAR);

and wouldn't you know it, it works normally for PPP even.

One *BIT* fixed it.  This must have been broken since the
import from
OpenBSD.

I'd appreciate testing to make sure this isn't a fix for a
hardware
inconsistency isolated to the Ultra 5/10.  (If any other
hardware even
uses sabtty(4).)

	Jonathan Kollasch

On Mon, Apr 17, 2006 at 02:02:24PM -0500, Jonathan A.
Kollasch wrote:
> I'd appreciate testing to make sure this isn't a fix
for a hardware
> inconsistency isolated to the Ultra 5/10.  (If any
other hardware even
> uses sabtty(4).)

I've commited it - if anypne finds problems with it, please
send-pr.
There are other machines that use it (U60 for example).

Martin

In article <20060417175553.GB656kirkkit.kollasch.net>,
	"Jonathan A. Kollasch" <jakllschkollasch.net> writes:
> Besides it's inability to handle native IPv6, SLIP's
296 octet MTU
> even precludes IPv6 tunneling (unless it fragments or
something
> automatically).

NetBSD's SLIP driver sl(4) supports larger MTUs. The exact
value is
architecture depended but should be at least 1500 bytes.

	Kind regards

-- 
Matthias Scheler                                  http://scheler.de/~matth
ias/

>>> I've been attempting to get a PPP connection
between two boxes
>>> using a null modem cable (with the 4-1&6
1&6-4 etc).
>> Unless this is a mockup of a dialup connection, my
experience
>> suggests that you would be better off using SLIP
instead of PPP.
> Ultimately this is supposed to be a dial-in server.

Ah, then yes, you'll want to get PPP working.

> Besides [its] inability to handle native IPv6,

This is trivial to fix.  I fixed it back in 2002 and even
wrote up the
fix; apparently nobody cared enough to do anything with it.
(ftp.rodents.montreal.qc.ca:/mouse/docs/ipv6-slip in case
anyone cares.)

> SLIP's 296 octet MTU even precludes IPv6 tunneling
(unless it
> fragments or something automatically).

Even my antique 1.4T systems accept "ifconfig sl0 mtu
1500"....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouserodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3
27 4B