cu not dialing 9600 baud systems

[aseidas]

Hello,
We use cu heavily to support customers and have been for years about two weeks ago we started having major problems with our call scripts that use cu to dialout, very flaky some customers worked other didn't. We called the phone company to check the lines, they said they were clean. We swapped out half of the 10 modems we have connected to a stallion serial concentrator , no difference.

I installed a brand new stallion card and panel still the same. I then moved all of the modems to another sco server replaced all cables & connecters, copied /usr/lib/uucp/Systems,Devices & Dialers & problems still persist. I believe I have narrowed it down to systems set to 9600 baud in Systems, 19200 systems seem to be fine. I am pulling my hair out !!! Any suggestions would be greatly appreciated. Please see examples from dialers, systems, and devices below:


Devices:
ACU tty0A00 - 19200 usrobT19.2 \D
ACU tty0A00 - 9600 usrobT9600 \D
ACU tty0A00 - 2400 usrobT2400 \D
ACU tty0A00 - 1200 usrobT1200 \D

Systems:
weil Any ACU 9600 15555555555 -\r\d-ogin:-\K\d-ogin:-\K\d-ogin: nuucp word: ****

tpc Any ACU 19200 15555555555 -\r\d-ogin:-\K\d-ogin:-\K\d-ogin: nuucp word: ****

Dialers:

usrobT9600 =,-, "" ATQ0E0&D2&C1&B1&M4&N6S0=0X4S2=043\r\c OK\r ATDT8,\T\r\c CONNECT
&usrobT9600 =,-, "" +++\dATZ0Q0H OK\r ATE0&D3&C1&N6X4S2=128 OK\r ATS0=1Q1\r


usrobT19.2 =,-, "" ATF1Q0E0&D2&A0&B1&C1S0=0X4S2=043\r\c OK\r ATDT8,\T\r\c CONNECT
usrobT19.2=,-, "" ATF1Q0E0T&D3&C1S0=0X4S2=043\r\c OK\r ATDT8,\T\r\c Speed



PLEASE HELP !!!

-Aseidas

 

[edfair]

Have you considered using the hayes2400 part of the standard dialers package. Seems to work well with the USR stuff I use.
Have you watched the modem indicators? Getting dialing commands to the modem?


Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[mrregan]

Has your /etc/gettydefs file been changed?

 

[aseidas]

Hi,

I have tried hayes2400 with the same results, also I looked at gettydefs as well but bening that I have tried moving all of the modems to another server running 5.0.6 with a totally different gettydefs file with the same result. Just for good measure I restored gettydefs from a year ago and did a diff on the origanal server the file had not changed. I am still totally lost on this, here is the ouput from cu there is an error initilizing the mode going to run with this for a bit.




Device Type ACU wanted
lockname(/usr/spool/uucp/LCK..tty0a00)
mlock tty0A00 succeeded
fixline(5, 9600)
processdev: calling setdevcfg(cu, ACU)
gdial(hayes9600) called
expect: ("")
got it
sendthem (ATB8Q0E1E0&D3&C1S0=0X4S2=043^M)
expect: (OK^M)
ATB8Q0E1E0&D3&C1S0=0X4S2=043^M^M^JERROR^M^Jtimed out
lockname(/usr/spool/uucp/LCK..tty0a00)
lockname(/usr/spool/uucp/LCK..tty0a01)
mlock tty0A01 succeeded
fixline(5, 9600)
processdev: calling setdevcfg(cu, ACU)
gdial(usrobT9600) called
expect: ("")
got it
sendthem (ATQ0E0&D2&C1&B1&M4&N6S0=0X4S2=043^M)
expect: (OK^M)
ATQ0E0&D2&C1&B1&M4&N6S0=0X4S2=043^M^M^JERROR^M^Jtimed out
lockname(/usr/spool/uucp/LCK..tty0a01)
getto ret -1
Call Failed: CALLER SCRIPT FAILED
Connect failed: CALLER SCRIPT FAILED
call cleanup(1)
call _mode(0)
Same, Call again, Detailed, Trans, Force Dial

 

[edfair]

Do you have any Direct devices to enable looking at the modems in interactive mode. Possibly to the point of dialing out from the command line. Sounds like something in the modems has been changed.
I think it is like
cu -l tty0a00 dir
ati4 to see the setups
And are all the ACUs pointing to the same port like your first post indicated?

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[aseidas]

I have directly connected to all seven modems and restrapped them with the same command set we have been using for years. They all tested ok (we use atl5l6l7 to see the setups) The example ACU I posted was just the first ACU there are six more blocks for each of the remaining modems on tty0A00,1,2,3,5,6,7, they are all exactly the same.I have had limited success with geting out to systems set to 19200, there are very strange symptoms when trying a 9600 baud system the call will sometimes hang and you have to kill the process manually...sometimes you recieve the error I posted previously sometimes you don't, if I change that system to 19200 it will dial, start handshaking but never negotiate a stable baud rate. I am thinking it is the phone lines but the syptoms seem to express themselves before the modems even dial. The phone company has checked the lines over and over and still claim no problems....still stumped

-Aseidas

 

[apeasecpc]

Your configurations are a little strange. You should not be defining the same device name "ACU" for the same tty "tty0A00" multiple times. My guess is that the "cu" program is only finding the first one.

It's ok to define the same device names for different tty's, but each tty should only use each name once. A little known fact is that you can call your devices anything you want; they don't have to all be called "ACU".

In your "Devices" try something linke this instead (you need to do this for every tty):

ACU tty0A00 - 19200 usrobT19.2 \D
ACU96 tty0A00 - 9600 usrobT9600 \D
ACU24 tty0A00 - 2400 usrobT2400 \D
ACU12 tty0A00 - 1200 usrobT1200 \D

Then specify the desired device for the appropriate speed in your "Systems" file:

weil Any ACU96 9600 15555555555 -\r\d-ogin:-\K\d-ogin:-\K\d-ogin: nuucp word: ****
tpc Any ACU 19200 15555555555 -\r\d-ogin:-\K\d-ogin:-\K\d-ogin: nuucp word: ****

Your "Dialers" file should be ok the way it is. After making the changes, make sure you disable and re-enable all of the ports, and delete any outstanding lock files.

 

[aseidas]

I took your suggestion and changed all of the devices and then updated Systems, still the problem persists. It was a good suggestion, but the devices file has been the same for 5 years with no problems. We have all of our communication vendors coming in tomorrow to troubleshoot the lines on site, I just don't want it to be my fault in the end

-Aseidas

 

[apeasecpc]

According to your debug output above, the modem is responding to your initialization string with an error message, and then the dialer program is timing out:

sendthem (ATQ0E0&D2&C1&B1&M4&N6S0=0X4S2=043^M)            
expect: (OK^M)                                            
ATQ0E0&D2&C1&B1&M4&N6S0=0X4S2=043^M^M^JERROR^M^Jtimed out

The dialer is expecting the modem to return "OK", but instead it is returning "ERROR". This means that the problem is with the initialization string or possibly the modem itself, NOT your phone line or your ports.

You said you swapped out half of your 10 modems. What did you swap them with? If they are not the same model as the previous modems, then that is probably your problem (I have sometimes seen changes in AT commands between different models of the same basic modem). You need to confirm all of the AT commands from your initialization string on the new modems, and make the necessary modifications so that the modems do not give the "ERROR" response.

I use the following dialer initialization strings for fixed speeds on US Robotic Sportster modems on my system. My "Normal9600" dialer would be equivalent to your "usrobT9600" dialer.

normal2400   =,-, "" \r\pATE1Q0V1M0S0=0S2=128&U0&N3 OK\r \dATDT\T CONNECT
&normal2400  =,-, "" \r\p\r\pATE1F1Q0V1M1X4\r\pAT&A3&B1&C1&D2&H1&I0&K1&M4&R2&S1\
r\pATS0=1S2=128&U0&N0Y0\r\pAT&W0\r
normal9600   =,-, "" \r\pATE1Q0V1M0S0=0S2=128&U0&N6 OK\r \dATDT\T CONNECT
&normal9600  =,-, "" \r\p\r\pATE1F1Q0V1M1X4\r\pAT&A3&B1&C1&D2&H1&I0&K1&M4&R2&S1\
r\pATS0=1S2=128&U0&N0Y0\r\pAT&W0\r
normal192    =,-, "" \r\pATE1Q0V1M0S0=0S2=128&U0&N10 OK\r \dATDT\T CONNECT
&normal192   =,-, "" \r\p\r\pATE1F1Q0V1M1X4\r\pAT&A3&B1&C1&D2&H1&I0&K1&M4&R2&S1\
r\pATS0=1S2=128&U0&N0Y0\r\pAT&W0\r

 

[aseidas]

We are still having problems with certain modems, timing out dialing into some systems, but not others, the modems I replaced were replaced with the same models we have used for years:
multitech: MT1932ZDX, MT2834ZDX
we have always used the usrobotics dialers with these modems and have never had problems, If you can look at the dialers and suggest another I might want to use ( I have tried hayes2400 with the same sporadic failures). I am willing to blame it on sunspots/global warming etc... but nobody here is buying it. I firmly believe that if you always do what you always did you will always get what you always got , something changed I just cant find it !!!

usrob9600 =,-,  "" ATQ0E0&D2&C1&B1&M4&N6S0=0X4S2=043\r\c OK\r ATDT\p\p\p\p\p8,\T
\r\c CONNECT                                                                    
&usrob9600 =,-, "" +++\dATZ0Q0H OK\r ATE0&D3&C1&N6X4S2=128 OK\r ATS0=1Q1\r      
                                                                                
usrobT9600 =,-, "" ATQ0E0&D2&C1&B1&M4&N6S0=0X4S2=043\r\c OK\r ATDT\p\p\p\p\p8,\T
\r\c CONNECT                                                                    
&usrobT9600 =,-,        "" +++\dATZ0Q0H OK\r ATE0&D3&C1&N6X4S2=128 OK\r ATS0=1Q1
\r                                                                              
                                                                                
usrob19.2 =,-,  "" ATF1Q0E0&D2&A0&B1&C1S0=0X4S2=043\r\c OK\r ATDT\p\p\p\p\p8,\T\
r\c CONNECT                                                                     
&usrob19.2=,-,  "" ATF1Q0E0T&D3&C1S0=0X4S2=043\r\c OK\r ATDT\p\p\p\p\p8,\T\r\c S
peed                                                                            
                                                                                
usrobT19.2 =,-, "" ATF1Q0E0&D2&A0&B1&C1S0=0X4S2=043\r\c OK\r ATDT\p\p\p\p\p\p8,\
T\r\c CONNECT                                                                   
usrobT19.2=,-,  "" ATF1Q0E0T&D3&C1S0=0X4S2=043\r\c OK\r ATDT\p\p\p\p\p\p8,\T\r\c
 Speed

-Aseidas

 

[apeasecpc]

It's not really the dialer that is the issue, a dialer contained in the /usr/lib/uucp/Dialers file is merely a name for reference by the /usr/lib/uucp/Devices file. What actually matters is the initialization AT commands defined in the dialer, which you can modify as needed. US Robotic modems are mostly hayes compatible, so many other modems will work with their dialer. However some modems have differences in their AT command structure requiring a small modification of the dialer, and this appears to be the problem you have encountered.

You need to read through your modem manual, identify the AT commands in your initialization strings that are not valid for your modem, and remove them from the initialization string (or replace them with the equivalent commands for your modem).

About the "something changed" issue, it is possible that the new modems just have a later firmware that errors on AT commands that didn't give an error with earlier firmware. I have seen this happen with some modems. Regardless of what caused things to break, your best solution will be to fix the initialization strings in your dialers.

 

[edfair]

I ran across the same sort of problem a long time ago (Xenix era) which required in depth work into the multitech command set. If I recall correctly I set up the correct initialization and reset strings as part of Dialers and called it from there. At about the same time I started using the modem gettydef token for modems but changed the rotation to point back at itself rather than step thru the 3 possibilities. Don't remember the tieins.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[aseidas]

Trying to cu directly into the modems is now giving me just about the same results, tty locks up and I need to go to another and kill the process, the dialers should not even be called when doing a direct connect....was going to try to direct connect and try the init string one command at a time.

-Aseidas

 

[PHV]

When using cu -l ttyXX I suggest to start with ATE1Q0 and to end with ~.

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[aseidas]

I have used cu directly many times, I would usally start and with the same commands you have suggested , the problem is neither of them work in this situation, after ~. the modem disconnects but the session hangs. The modem is unresponsive to any other commands.

 

[fredericofonseca]

I know I'm being heretic, but can you try and connect that modem to Windows box and try connecting directly to it (comx)? Assuming you can have a look at the setup and change as needed.


If the modem is failing on connect like that it is also possible that the prob is cable related.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[aseidas]

Yes this has been done to every modem, I have restrapped and replaced all cables and db25->rj45 adapters. The modems were working all morning, I can pinpoint when they all stopped working again to when someone tried to access a particular system, the modem on the other end picked up started to handshake then recieved garbage on the line, after that all modem timeout. I know this sounds strange but it is happening, this is not a new setup we have been doing this for years.


-Aseidas

 

[edfair]

The ~. is the OS signal to disconnect and the OS should go into hangup mode based on the hangup string.
If it doesn't disconnect, I would suspect that the modem has changed communication speed with the OS. You should be able to watch the indicators and see if DTR drops.

How about hanging a 9600 baud terminal on the Stallion line to one of the 9600 modems to parallel what the modem gets and see what is coming out of the OS to it.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[apeasecpc]

Another possibility for the modem hanging is the break character being changed or erased by a prior modem configuration, which would prevent the hangup routine from accessing the modem. You can bypass this and a number of other problems by sending the command to restore the modem to factory defaults. I have my modems configured to do this any time the port is reset.

 

[aseidas]

This is kind of what we were thinking of trying next, thanks for the hint, where would I add this in the dialers string?

-Aseidas