Problem with PortServer TS8 on AIX 5.3 w/ Multitech Modems

I have an AIX 5.3 host, using the realport drivers, and a Portserver TS8 using the Digi branded RJ45 to DB25 cable (model 61020024F). The modems are all Multitech MT5634ZBAs. The firmware on the Digi device is the latest, as is the realport driver. I use these devices to send faxes using Esker’s Vsi-fax product.

It appears there is a significant amount of problems with handshaking between these devices and the recipient fax machines (whether those be electronic or paper-based). I have referenced the Digi’s ‘Modems under UNIX’ guide, as well as the Realport installation guide, but I cannot seem to solve this issue. Maybe someone can assist me with the questions below.

  1. Now that ‘realport’ is an option in the Digi device, is it better to configure the devices as ‘realport’, or should you still use ‘printer’ as the realport installation guide [dated 10/14/2005] says?

>> According to userid’s post (Re: PortServer TS 2 H on 3/20/2007), either printer (prn) or realport (rp) is a viable option.

  1. Is it better to try to use Hardware flow control w/ these devices to ensure a more reliable handshake? It seems as long as the port is set the same way, the ‘modem under Unix’ guide states either type of flow control should work.

  2. It’s my understanding that if you are using hardware flow control, you need to set ‘altpin’ for the signals to be passed effectively to the device, when using the Digi RJ45 to xxx (in our case DB25M) cabling, is that accurate?

>> The purchased Digi cables use 10 pin RJ45 connectors, therefore the alpin setting isn’t necessary. Altpin is just a way to support the more common 8 pin RJ45 connectors, for those who use custom ‘cable legs’.

  1. Does anyone know of any additional tips to obtain better handshaking when using devices in this manner?

Any help that anyone can provide me on this topic would be sincerely, appreciated. Thanks.

Message was edited by: asdeal; Some answers added.

Answers to your questions…

  1. Now that ‘realport’ is an option in the Digi device, is it better to configure the devices as ‘realport’, or should you still use ‘printer’ as the realport installation guide [dated 10/14/2005] says?

A: At code level they are both the same, so it really doesn’t matter. The “realport” device profile was added to make more sense basically.

  1. Is it better to try to use Hardware flow control w/ these devices to ensure a more reliable handshake? It seems as long as the port is set the same way, the ‘modem under Unix’ guide states either type of flow control should work.

Hardware flow is always more reliable than software flow, but not always necessary. Low baud rate terminals and printers can typically get away with software flow, unless over a very laggy network connection. Times when it would be required are when using a modem, baud rate set to high speed, or over laggy network connections. The difference is that in software flow, you’re relying on the Xon/Xoff characters (data) going upstream to tell the host to stop, whereas with RTS/CTS (signals) its basically a switch being toggled.

  1. It’s my understanding that if you are using hardware flow control, you need to set ‘altpin’ for the signals to be passed effectively to the device, when using the Digi RJ45 to xxx (in our case DB25M) cabling, is that accurate?

Not really. Altpin is a workaround to allow people access to the DCD signal when using 8-wire RJ45 cable in a Digi RJ45 serial port. Since our RJ45 socket has 10 wires, if an 8-wire/cat5 cable is used DCD is omitted from the cable. Enabling altpin allows access to the DCD signal once again by swapping the meaning of pins 2 and 10 on our 10-wire interface. With altpin=on, DSR would no longer be available, but DCD would.

  1. Does anyone know of any additional tips to obtain better handshaking when using devices in this manner?

http://ftp1.digi.com/support/terminalservers/portserverts816/portserverts16dom/cabling/conversion.pdf

http://ftp1.digi.com/support/cabling/flow_control.pdf

http://ftp1.digi.com/support/cabling/signals.pdf

  1. The “rp” and “prn” device types will both work with RealPort as they are both “passive” settings.

  2. Anytime modems are used, hardware flow control should be implemented (rts setting in smit).

  3. Altpin does not affect flow control and only applies to carrier detect (DCD). You will want to activate altpin only when using an 8-wire serial cable for connecting your modem.

  4. With the latest driver build, there is the addition of a utility: /usr/lbin/tty/dpa-ncxa. This utility will allow you to monitor the serial activity including flow control signals and can be quite useful for troubleshooting.

I’m having a similar problem, so I thought I’d tag onto this post. I recently installed four Digi TS’s; 1 TS8, 1 TS4, and 2 TS2’s. Like the OP, I am using them to connect MultiTech modems (a little older models - MT1932 and MT2834) to an AIX 5.3 host for use with VSI-FAX. Since installing these devices we have been getting complaints from our customers, who say that some of the faxes they are receiving are of very poor quality. We’ve been using the same configuration (AIX, MultiTech modems, and VSI-FAX) for quite some time, except we were using old Chase IOLAN+ TS’s to connect the devices to the host. So the “x-factor” seems to be the Digi’s. The one other import thing here is that so far (about three weeks) all the complaints have come from two remote sites that where the TS2’s are located. These remote sites are connected to the host via 768k frame-relay links. The TS8 is on the same 100 MB LAN as the AIX host, and the TS4 is a remote site, with a full T1 connection back to the host. So, a few questions:

  1. If the OP reads this, did you ever find a solution to your problem?
  2. Is there anything else that hasn’t been mentioned in this thread that I should be looking at?
  3. May be a red-herring here, but I’m looking at the fact that the slower remote networks are having the problems, and wondering if this could have something to do with the “WAN Link Speed” setting in AIX. When I fist setup the devices I entered 768000 in this field, but then the complaints starting coming in. So, I took off this setting and we are still getting complaints. Should I be using this field, and if so, what’s the proper way to enter the number for a 768k link? (There is no help in SMIT for this field, and I couldn’t find anything in the documentation.)

Any help would be appreciated.

TIA,
John

The “Wan Link Speed” setting may very well have an important effect on this, but I’m not sure that 768000 is the correct setting there. What you want to set that value to is the CIR or amount of unused bandwidth on the link, not the full amount (bandwidth which also may be being used by other things at that remote site).

I’d recommend a lower value to better tailor the driver communication with that of the actual bandwidth it has available to use.

Alright. Thanks for everyone’s help. I still do not have a solution, and I feel like I’ve potentially overlooked some items.

  1. I have two (2) AIX 5.3 hosts, both running vsi-fax accessing the same two(2) digi Portserver TS8’s. Though they access different devices, they both have all the ports of the Digi devices configured. Is there some sort of port masking I should be doing to prevent them from messing with each other’s communication at a port level, or does realport handle this without additional configuration?

  2. I have one Multitech 5600ZDX (class 2 only fax, 14.4kbps) modem on one of the Digi’s. This device uses the rockwell chipset, it works PERFECTLY.

However, I have two “fancier” (read: more expensive) Lucent chipset Global V-92 Multitech MT5634ZBA series (class 2.1 fax, 33.6kbps, ‘Super G3’) modems, and these seem to have incredible problems communicating! Anyone have any ideas here?

Please note: Both the 5600ZDX and the 5634ZBA are used w/ Esker’s Vsi-fax product They are both configured as 19200 8N1 realport devices using software flow control during this testing.

I was told int he previous post to try to to use hardware flow control for it’s reliability, but when I try to configure it, it seems to fail, despite Esker (vsi-fax manufacturer) telling me it’s possible if both the device, and AIX 5.3 support it. It seems like this should be possible. Has anyone achieved success using HW Flow control and Vsi-fax on AIX 5.3?

My ideal here, is to see the success I am seeing with the 5600ZDX on the 5634ZBA, or at the very least to understand what is happening, before I replace my 5634ZBA modems with the cheaper 5600ZDX series, and have to explain to management why that is…

What I have tried:

  1. I have tried having multitech upgrade my 5634ZBAs to the latest firmware (ver 1.32b): NO SUCCESS

  2. I have tried using the newer version of Vsi-fax, version 6.0 on my development box: NO SUCCESS.

  3. I have tried disabling the ‘Super G3’ (fax class 2.1) fax class in Vsi-fax: NO SUCCESS.

I realize, as I re-read this post it may sound like more of vsi-fax issue, but I’m not fully convinced where in the process I’m suffering handshaking problems. Has anyone seen anything like this? Anyone who can provide me additional insight, it would be very much appreciated.

Thanks,

Adam

Message was edited by: asdeal

I have no idea as far as the two MT modems go, but if the ZDX works and the ZBA doesn’t, it would seem to be a modem problem to me.

I also see flow control as a potential issue here, because modems by default are set to hardware flow control, and that’s what I’d recommend if it were supported by the application. If only Xon/Xoff is supported, you’ll need to ensure the modems are set that way by AT commands in the init string of the application or stored in the modems, as well as setting the appropriate lsattr attibutes on the tty AIX-side. The reason Xon/Xoff flow is a bad idea on modems is due to data compression, in that the Xon/Xoff characters get compressed with the data being transferred over the modem and delayed, therefore causing potential data loss.

Vsi-fax’s reply to the flow control piece is:

Hi Adam,
With v6.0 we have configured the c2modes.ini file to allow hardware or software for each modem entry. The problem is that your specific OS may not support these for your port configurations. So you you try to switch the VSI device to hardware and you receive that message, it is not support by your OS and port configurations on your server. So you would have to stay with software flow.

Regards,
Brian


It was my understanding that AIX 5.3, Digi (Realport on AIX), and the MT series of modems all support hardware flow control, so this doesn’t quite add up to me. I’m contacting vsi-fax via voice for clarification. I’ll post what I find. Has anyone had success w/ just Digi / Realport and AIX 5.3 w/ hardware flow?

Thanks again,

Adam

Message was edited by: asdeal

Hardware flow IS supported by the Realport driver in all supported operating systems, AIX included. To enable this you’d select “RTS” as your flow control type in the tty attributes. This of course requires the pinning-in of the RTS/CTS signals in the cable between serial port and modem. The modems should have Multitechs setting for hardware flow (&E4) set by default. Not sure how to setup hardware flow in VSIFax, but I suspect it would be a line in the config file.

You mentioned ‘pinning-in’ of the signals. Is this not already done by default w/ the 10 pin Digi “RJ45” cable from the Portserver TS8 to the (DB25) of the modem? Please advise. Thanks again, as always!

Yes, all Digi serial cables are fully pinned. Some customers use 3-wire cables (RxD, TxD, SG) though, which is why I mentioned it.