Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Feb 2000 12:08:11 +0100 (CET)
From:      Juergen Lock <nox@jelal.kn-bremen.de>
To:        ptacek@dashmail.net
Cc:        <freebsd-hackers@FreeBSD.ORG>, <freebsd-questions@FreeBSD.ORG>
Subject:   Re: modem program... Help continued...
Message-ID:  <200002261108.MAA44976@saturn.kn-bremen.de>
In-Reply-To: <01e301bf7ff2$2aa60600$0301a8c0@Ptacek>
References:  <Pine.BSF.4.21.0002241741310.17368-100000@boris.netgate.net> <200002252012.VAA04133@saturn.kn-bremen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Sorry i should probably have said the modem needs to be configured
right to work `the unix way'...

In article <01e301bf7ff2$2aa60600$0301a8c0@Ptacek> you write:
>Well thanks to some examples I seem to have access to the
>modem signals.  Unfortunately when I drop the DTR nothing
>happens.  I have played with setting the &Dn and other values
>but nothing seems to work.

 Well yes the usual setting is &d3, if that doesn't do it (thats
hangup + reload configuration), and this particular modem doesn't
just want some other command to set it (do you have a manual?  some
also have online help), then i'd say the modem is junk and should
be returned...  (and post what it was so others know what to avoid.)

>  Also it seems that the carrier detect
>signal is always high, even after a NO CARRIER.

 you should be able to fix that too (usually(?) thats &c1),
if not, see above.

 oh, of course you should save the configuration after changing
this and the DTR setting, thats usually &w.  so, assuming the
commands are correct for that modem, give it a `atz' followed by
`at&c1&d3&w', then try again.  (btw don't put commands after the `z',
that only works on `some' modems as there are ones that just jump
to their cold boot entrypoint when they see the `z', and then the
rest of course gets ignored.  i was told even hylafax had (has?)
this bug, go figure...)

 and if you want to check the modem's behaviour without having to
debug your own source at the same time then install the kermit port,
do a kermit -l <modemline>, say `con'nect and type the escape
char it'll show then, followed by a '?', then you get a list of
commands.  one will show the control lines status, another will
hang up (drop DTR), etc.  and of course you can chat with the
modem or dial it too.  (some also have an analog loopback test
(&t1 on my old one) or one where they loopback and generate test
data (&t8 on mine), then you don't even need to dial anywhere to
test the CD/DTR settings...)

>  I have also
>tried clearing the CLOCAL flag to see if I get a signal (HUP),
>but I am not getting one.

 well as long as the modem still leaves CD always on how do you
think this should work? :)

>  I have also tried to get the HUP signal
>by using the +++<delay>ATH<CR> command with no success.
>
>Currently I have a test program that I will include below, and it
>is dialing my other PC (hyperterminal) just to see if I can get the
>connection to work.
>If I am missing something please let me know.  Maybe I just
>have a bad modem, I will try to look for a different one (it is
>internal, but that shouldn't matter, should it?) ;

 It shouldn't, but an external still is better since you can then
troubleshoot by just looking at the LEDs, and you can (hard) reset
it without taking down the entire system.  (and yes sometimes
modems crash too, or get confused so that you want to reset them,
tho that of course varies between models.  and some also have front
panel buttons so you can force them to hangup or answer or transfer
the call to/from a connected phone...)

 Oh and you also avoid the trouble of possibly having to return
a `win'modem (shouldn't that be `you lose' modem?), some salespeople
are too clueless to even know the difference.  (or their suppliers
may have lied to them... :( )

 [test program snipped, didn't try it...]

 another thing, if all you need is to dial the modem to run some
program over the connection you could also try the xchat program
in /usr/src/gnu/libexec/uucp/contrib, or maybe even the more simple
/usr/bin/chat is enough.  no need to reinvent the wheel...
(of course depending on whats at the other end maybe you could also
use ppp... then you'd treat the link as just another (slow) network
connection, i.e. use tcp/ip.)

 HTH,
-- 
Juergen Lock <nox.foo@jelal.kn-bremen.de>
(remove dot foo from address to reply)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002261108.MAA44976>