🚀 go-pugleaf

I am trying to connect a "downstream" site who is using Waffle 1.65
under DOS 5 without FOSSIL drivers.  He has both a Netcomm E7 and a 
Maestro V.32 modem, although these model identifiers may not mean 
much outside of Australia.  The whole thing is running on a 486/33.

We have no problem getting our modems to connect.

His problem is that uucico reports carrier loss while his modem shows
the DCD signal is still high.  Initially, his uucico was failing to
login because it wouldn't receive my login prompt - his trace reported
loss of carrier instead.  As a last resort, he removed the \m parameter
from his scripts file.  Now, he can (blindly) log in but does not respond 
to my "Shere" message - again his trace reports loss of carrier instead.
We cannot see how to turn off uucico's carrier detection once a connection
is established.  Nor do we want to, really!

We have run up a hefty phone bill trying every combination of init strings
we could think of, for each of his two modems.  The same behaviour results
for all reasonable combinations, including both &C0 and &C1.  &C0 SHOULD tell
the modem to keep DCD up, no matter what happens.

Now, the REALLY strange thing is that connections using both Procomm (login 
to an interactive acount) and UUPC/extended (to a uucico shell) were simple 
and painless.  He doesn't want to stay with UUPC because of its relatively 
poor news support, plus he's attracted to Helldiver as a user agent.

I've asked him to check out his cable to make sure that DCD is propagated 
reliably (no loose pins), but that sounds a bit feeble when UUPC and Procomm
don't seem to have any problem.  I also suggested that he might have configured 
those other programs to ignore hardware DCD - but I doubt that is even possible 
with UUPC.

SO.  Has anyone seen anything like this before?  Has anyone got any suggestions?
Are there any neat debugging tricks we should be trying?  Would anyone care to 
speculate why UUPC/extended behaves differently?  We've run out of ideas, except 
for the unlikely theory that he has a hardware fault.

All assistance gratefully received...


-- 
Nick Langmaid  nick@brimbank.apana.org.au  Melbourne, Australia  +61(3)336-3228