acceleport on redhat ES 2.1

Does anyone know whether the acceleport xp (8port) will work with RH ES 2.1. I don’t see any reason why not, but then again it is not explicitely listed as a supported platform (RH ES 3.0 is listed). Thanks already …

Asbjorn

The released driver will work with AS 2.1. Use the following installation syntax:

rpmbuild --rebuild --define DISTRO=REDHAT_AS_21 (driver)
rpm -i /usr/src/redhat/RPMS/i386/dgdm-1.1-1.i386.rpm
insmod dgdm
/proc/dgdm/mknod

Thanks, I know that it works with RH AS 2.1. What about RH ES 2.1? Are you saying to run it as if it were RH AS 2.1?

Asbjorn

Message was edited by: luedtkea

The only difference between the two that I am aware of, is the level of support.

There is also a DISTRO=REDHAT_ES_21 installation flag.

Hope this helps.

great! thanks!

Asbjorn,

Was curious if you had any luck loading the acceleport on ES 2.1? I loaded it on 2.1 and cannot get the ports to hang up correctly - dial out works fine. RH And Digi support have not been helpful.

Typically, a hang up is triggered when the modem drops DCD (carrier detect).

The signal activity can be viewed by selecting the DPA option from the mpi menu.

If you are using an eight (8) wire cable, please be sure to issue the altpin setting in order for the DCD signal to function correctly.

Two other methods of hangup, in addition to the DCD drop UserID0 mentioned, are for port to drop DTR, or for the application to send command +++ATH0.

DTR drop can also be monitored from the same program UserID0 mentioned. +++ATH0 hangup string could be tested by doing a cu to the modem port, connecting to a distant modem, then typing the string in manually.

No problem with ES 2.1. I only use the digi board for terminals & printers, not modems.

FYI - using 8 port internal pci modem
Tried monitoring DPA with no success. (although no modem expert so I was not sure what to look for) Tried sending the +++ATH0 connected via Kermit to the port - no hangup. Intially port will pick up, but subsiquent attempts to dial into that port are not successful. Shouldn’t the port eventually drop DTR on it’s own if other end no longer connected?

The DTR signal originates from the serial port, i.e. as long as the port is open, DTR will be present. This signal behavior can be modified by an application, which is why a lot of communication/fax programs will drop DTR for approx. 2 seconds to disconnect a call, regardless of whether it was incoming or outgoing.

For the +++ATH0 test, open the port with Kermit and dial into another modem. Once you see a “CONNECT” message (carrier is established), type the command. Also, while in Kermit but not connected to another modem, what is the output of ATI3?

Output of ATI3 = V800069_M2-56_DS