thad@cup.portal.com (09/23/88)
Has anyone succeeded in connecting two UNIX-PCs via a single serial port on
each system and having bi-directional uucp and mail function between them?
I attempted this and, after using a DLM (data line monitor) on the serial
port, discovered that each system's login herald would be interpreted as a
login attempt by the other system with the result being each system would
"fight" the other. Actually brought one system to its knees until I pulled
the cable.
The "fight" occurs when both systems have their (respective) serial port
configured as "CALLER and HOST.
When one system is configured as "CALLER" and the other as "HOST", there is
no conflict, but mail and uucp traffic only flows from the CALLER to the
HOST; uucp or mail on the HOST remains queued forever.
I cannot afford the luxury of dedicating TWO serial ports on each system
simply for uucp/mail between them (esp. since one system only has a single
serial port).
Both systems have 3.51 Foundation Set software.
The null-modem cabling I'm using:
System A, tty004 System B, tty000
(1)-----------------------(1)
(2)-----------------------(3)
(3)-----------------------(2)
(4)-----------------------(5)
(5)-----------------------(4)
(7)-----------------------(7)
(6)(8)-----------------------(20)
(20)-----------------------(6)(8)
The UNIX-PC docs "claim" that inter-system mail and uucp is trivial; does
this imply that one must use StarLan (or something?)
Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]david@ms.uky.edu (David Herron -- One of the vertebrae) (09/24/88)
set one of them up to be the only one which calls.
Have that one call every 5 minutes or whatever interval you can stand
effectively you have what you want even though it isn't exactly
what you want.
This was one of my earliest strategies in the old days when I
was just starting out with UUCP & Mail & such.
--
<-- David Herron; The official MMDF guy of the 1988 Olympics <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- What does the phrase "Don't work too hard"
<-- have to do with the decline of the american 'work ethic'?dave@arnold.UUCP (Dave Arnold) (09/24/88)
In article <9377@cup.portal.com>, thad@cup.portal.com writes: > [...] > I attempted this and, a DLM (data line monitor) on the serial > port, discovered that each system's login herald > would be interpreted as a > login attempt by the other > system with the result being each system would > "fight" the other. I know one thing: You have to be running a getty on both systems that wake up, and give the login prompt only until DCD is asserted. uugetty does this but isn't really widely available... But... There was a bidirectional getty front-end posted to comp.sources.unix several years ago. Besides all this, there are still some things to watch out for, and don't know the details. I remember a big discussion about this last year in comp.sys.att, or unix-pc.general. randy@chinet was very involved. I would really like to bring this one back, I found it very interesting at the time, but was to busy to read the discussions. I have some time now! Did anybody save this discussion? The subject was "uugetty's fighting" or some such thing. -- Dave Arnold dave@arnold.UUCP {cci632|uunet}!ccicpg!arnold!dave
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/25/88)
In article <9377@cup.portal.com> thad@cup.portal.com writes: >Has anyone succeeded in connecting two UNIX-PCs via a single serial port on >each system and having bi-directional uucp and mail function between them? Yup. I've seen several systems working this way. >The "fight" occurs when both systems have their (respective) serial port >configured as "CALLER and HOST. Yes, it's called "babbling gettys", and it happens to any Unix systems when configured this way. >When one system is configured as "CALLER" and the other as "HOST", there is >no conflict, but mail and uucp traffic only flows from the CALLER to the >HOST; uucp or mail on the HOST remains queued forever. This is not quite true. In that setup, communication will flow in both directions, but a "conversation" can be initiated only by the "CALLER" system. This means that mail from the HOST will be queued until the next time the CALLER calls. You can make the CALLER machine poll the HOST periodically using cron; causing a poll every half-hour or so is usually quite acceptable for directly connected machines. crontab entry: 08 * * * * /bin/su uucpadm -c "/usr/lib/uucp/uudemon.hr > /dev/null" /usr/lib/uucp/uudemon.hr entry: rm -f /usr/spool/uucp/STST.${HOST} uucico -r1 -s${HOST} Another possibility is to use a special version of "getty" which doesn't "babble" (usually these work by not doing any output until they see something that looks like a login attempt). Several of these exist, usually called "uugetty". -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com
thad@cup.portal.com (09/26/88)
A lot of useful suggestions have arrive re: my plight of getting two systems to each be able to call the other (and avoiding the herald vs. login "fight"). I intend summarizing all along with a description of what finally functions. Among the suggestions: 1) get HDB (aka BNU); the problem has been solved 2) continue with one system as CALLER and the other as HOST, and have the CALLER ``poll'' the HOST periodically. Item (2) seems interesting; how does one ``poll'' the other system in order for material there destined for the CALLER be transferred? This requires more than just a crontab entry which calls the other system, right?
thad@cup.portal.com (09/26/88)
Re: the 3B1 vs. 7300 Fight, Round One, it appears there WON'T be a Round Two!
With many, MANY thanks to:
ditto@cbmvax.UUCP (Michael "Ford" Ditto)
who wrote:
``
You can make the CALLER machine poll the HOST periodically using cron;
causing a poll every half-hour or so is usually quite acceptable for
directly connected machines.
crontab entry:
08 * * * * /bin/su uucpadm -c "/usr/lib/uucp/uudemon.hr > /dev/null"
/usr/lib/uucp/uudemon.hr entry:
rm -f /usr/spool/uucp/STST.${HOST}
uucico -r1 -s${HOST}
''
Thad Floryan [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]