We have four Portserver II’s cabled to four banks of Starcomm modems. For some unknown reason, the modems are continuosly being sent an initialization string randomly about once per minute. This string causes any modem that has been called into to hang up immediately if it hasn’t yet established a solid connection end to end. If the timing is right and both remote and host modem do connect and DCD is asserted, the string doesn’t seem to cause any problems. But, it still occurs. There was ALSO a problem with the PortServer dropping DTR about once a minute as well. For now, I have configured the modem to disregard that signal. Why the constant intit string? Is this RealPort or the AIX O.S. doing this? HELP!!!
To eliminate the possibly of the PortServer sending data to the modem, you will want to confirm the “dev” setting is “rp” (on the latest firmware) or “prn” (for older firmware). From the root prompt of the PortServer:
#> set ports
If the dev setting is not “rp” or “prn”:
#> set port range=(port#) dev=prn
A reboot should be performed after changing this setting:
#> boot action=reset
If the behavior persists, you will want to start looking at the AIX configuration on the corresponding ports to determine whether an init string is configured (i.e.: /usr/lib/uucp/Devices).
Hope this helps.
According to the modem manufacturer, the terminal server shouldn’t be allowing any data to the modem once Ring Indicator has indicated an incoming call. It’s the fact that an initialization string is being allowed through while call set up is taking place that is hanging up the modem. Is there a setting in the PortServer that can address this?
Thanks!
Thank you for responding. Yes, the device type is set to “rp”. Any clue as to the continuous dropping of DTR? Is it possible that RealPort, the OS, or the application is always testing for a good line? One big question: Can we do without RealPort entirely and just use the PortServer as a standard terminal server?
Thx!
Yes, it is possible the DTR behavior could be coming from the O.S./application. I have seen instances in Linux where if mgetty has a problem initializing the port, it will retry every 5 minutes resulting in similar behavior.
Are you able to view the port settings from the RealPort host (ditty)?
What operating system are you running? Some are DCD sensitive and have specific devices to be used for modems.
You can use the PortServer II without the RealPort driver. More information on this configuration is available here:
http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=388
The OS is AIX Version 5.2.0.0
Thank you for the added information! I will be doing some additional testing today and will update this forum with the results.
According to the modem manufacturer, the terminal server shouldn’t be allowing any data to the modem once Ring Indicator has indicated an incoming call. It’s the fact that an initialization string is being allowed through while call set up is taking place that is hanging up the modem. Is there a setting in the PortServer that can address this?
Thanks!
(I posted this in the wrong place earlier…)
“terminal server shouldn’t be allowing any data to the modem once Ring Indicator has indicated an incoming call”
I believe the modem manufacturer is in error, as putting the Portserver in a dev=rp configuration basically removes it’s intelligence from the equation. The reason I say this is because dev=rp is a passive state which allows the serial port to be controlled by the Realport driver. So, any init string or DTR drop is likely coming from either AIX itself, or the application you run on that serial port.
Also, dropping DTR is a common way for an application to try and “hang up” a port. The fact that the init string and DTR drop are happening about once every minute tells me the application is trying to initialize the modem and isn’t seeing what it expects, so it assumes the modem is offhook and tries to hang up the modem, then re-initialize it. This is common behavior for most fax/data programs that use modems, although some send a soft hangup of ~+++~ATH0 rather than drop DTR.
At this point, I recommend contacting Digi Tech. Support directly. It would be good to provide details, such as, the firmware version, cabling pinouts and the configuration settings from the PortServer II (cpconf term).
Hopefully, this information will help to pin-point the origin of the rogue initialization string.
Thank you! I have been avoiding that since I don’t think Realport is the problem.
I appreciate the input! I am convinced as well that the application is sending the init string. There is just no apparent way to correct this from there. We may have to live with the fact that incoming calls will have to make several attempts before they connect…
Most of these types of modem applications have some sort of either text config file or a place in a GUI where the AT string exists. If you know what string is being sent, you may be able to locate that portion of the config file for the application and disable it somehow.
I know in the GUI where the string is specified. I have even removed it, but then the app thinks the modems are no longer available because an “OK” wasn’t returned. In fact, I’ve stripped the init string down to “AT” and and that works to satisfy the app.