ami@kodkod.usc.edu (Ami Motro) (04/01/89)
I am trying to connect a 2400 baud Hayes-compatible modem to a 3b2/310 running 3.2.2 -- and I am having a problem: I can originate calls (using cu, uucp, or manually via kermit) at 2400 baud without a problem, and I can get it to auto-answer (i.e., login remote users) at 1200 baud without a problem. But somehow I can't get it login remote users at 2400. The modem seems to be ok: if I set it in auto-answer, and "cat" the port, all the characters entered on the remote terminal appear correctly on the screen. Similarly, if I use kermit at both ends, they send and receive ok. But if I put a "getty" on the port, it echoes junk to the remote terminal. Issuing "break"s at the remote terminal does get it to cycle through the baud rates (I check it by sending a break on the sending port, and then running "stty </dev/ttyxx" on the receiving port), but it never logs the user in. To start "getty" I have a script that (1) talks to the modem over the port (get it into answer-mode, cancel echo, etc.), (2) edits /etc/inittab to respawn "/etc/getty 2400 /dev/ttyxx" and (3) call "telinit q". Occasionally (once out of 20 or 30) it does work ok... I tried lots of other "let's change this and see if it helps", without any luck. Any advice would be appreciated! Thanks. Ami Motro (ami@cse.usc.edu) I am not sure about the current uucp address. If you can't access the internet please post your answer.
les@chinet.chi.il.us (Leslie Mikesell) (04/03/89)
In article <16215@oberon.USC.EDU> ami@kodkod.usc.edu () writes: >I am trying to connect a 2400 baud Hayes-compatible modem to >a 3b2/310 running 3.2.2 -- and I am having a problem: [... problem is at 2400] >To start "getty" I have a script that (1) talks to the modem over the port (get >it into answer-mode, cancel echo, etc.), (2) edits /etc/inittab to respawn >"/etc/getty 2400 /dev/ttyxx" and (3) call "telinit q". This is probably caused by your modem spitting out a "CONNECT 2400" message at 1200 baud or whatever speed you used last. This causes getty to change speeds and as you have noticed, it requires a "break" signal to cycle once you are switched to a lower speed than the connection. If getty is set to a higher speed than the connection, almost any character will give the effect of a break signal. Anyway, the solution is to forget the tricks you are playing with getty and use /usr/lib/uucp/uugetty instead. Also, set the modem so that it only provides "carrier detect" when carrier is present. This wil require you to add a ",M" to the end of the device name in Devices and add a "\M" to the beginning and a "\m" to the end of the Hayes dialer script in Dialers to allow dialing out without the fake carrier. Most modems don't raise carrier until after they have sent the "CONNECT" message, so uugetty won't see it anymore. These tokens were added in SysVr3.1 and should be documented by now - at least in the release notes if not the normal place. The Dialers and Devices files should have comments explaining them in any case. Les Mikesell
fmcgee@cuuxb.ATT.COM (Netnews Administrator) (04/03/89)
In article <16215@oberon.USC.EDU> ami@kodkod.usc.edu () writes: >I am trying to connect a 2400 baud Hayes-compatible modem to >a 3b2/310 running 3.2.2 -- and I am having a problem: >I can originate calls (using cu, uucp, or manually via kermit) at 2400 baud >But if I put a "getty" on the port, it echoes junk to the remote terminal. >Issuing "break"s at the remote terminal does get it to cycle through the baud >rates (I check it by sending a break on the sending port, and then running >"stty </dev/ttyxx" on the receiving port), but it never logs the user in. This is really strange; it *SOUNDS* like you have everything set up okay, especially since the only thing that doesn't work on the port is getty. >To start "getty" I have a script that (1) talks to the modem over the port (get >it into answer-mode, cancel echo, etc.), (2) edits /etc/inittab to respawn >"/etc/getty 2400 /dev/ttyxx" and (3) call "telinit q". This is probably unnecessary. You can set up a sequence of baud rates that you'd like your tty's to go through as the calling process sends BREAKS down the line. It's described in gettydefs(4). Any particular reason you chose to do it this way ? I'd also try uugetty if you have it. -- Frank McGee, AT&T Tier 3 Indirect Channel Sales Support attmail!fmcgee