From: Mark Stosberg:
>> > Trying a new modem (US Robotics external 56k serial modem) did help
>> > slightly. With it, we consistently connnect, but then after a short
>> > pause the connection is dropped. This is easily reproduced  in
>> > "minicom": (Using the Sprint TAP modem number here). 
>> > 
>> >   ATDT18886561727
>> >   CONNECT 31200/ARQ/V34/LAPM/V42BIS
>> >   
>> >   NO CARRIER 
>> > 
>> > I'm out of ideas here. This phone line is only used for this
outbound
>> > service, although our alarm system also uses it for outbound
alerts. 
>> > 
>> > Any suggestions for possible causes or further troubleshooting
>> > approaches are appreciated. 
>> 
>> Does that modem support Unimodem Diagnostics? What do you get from a
>> '#UD' command right after the failed connection attempt?
> 
> Bob,
> 
> Thanks for the response!
> 
> I tried that with Minicom, and the prompt just goes back to the hover
> over the "#" sounds and sits there. From some quick Google searches, I
> didn't find any mentions of this modem supporting that. 
> 
> I'm also not familiar with the details of the TAP protocol. After the
> CONNECT, who should speak next? From looking at the qpage source code,
> it looks like we might be waiting for "ID=" to sent from the remote
end,
> and it is not. 
> 
> That would make me suspect the remote end, except that multiple remote
> modems are responding the same way. 
> 
>    Mark

Mark,

The only tap I am familiar with is /dev/tap virtual Ethernet device, as
I am currently working on a project that makes use of this interface.
Since you get the connect message from your modem, they were able to
negotiate a reliable connection. So you have to assume that you do not
have any phone line issues. Then it becomes a matter of seeing the
correct handshake sequence between the two systems. I would expect the
answering system to start that conversation. The NO CARRIER message
suggests that the other end dropped the connection, or hung up on you
instead of sending the opening message. That should be worth filing a
trouble report.

Is it possible that those serial ports have been disabled, or that
process has been shut down? It is possible the process died without
disabling the auto-answer status of the modem. Some of those modems are
just too smart for their own good.

Please do not CC me on this thread. I can read it just fine from the
list.

Bob McConnell
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to