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>