modem issues

[Fred Martin_1]

I have a modem connected to an RP5450, running HP-UX 11.11.

The modem is set up in SAM on a PCI Mux, as /dev/ttyd2a1, HW: 0/4/0/0

The modem has been behaving flaky lately. It's used for faxing and faxes fail 30% of the time.

I've replaced the modem, cables, even the phone number/dial tone, etc. etc. and now just want to try re-starting any processes related to it on the unix box.

Can someone tell me what I'd need to do, short of booting the server. Can it be done in SAM?

Thanks,

Fred

[Bill Hassell · Accepted solution]

Fax success requires two parts -- the local system and modem, and the remote fax. Your fax software should have a detailed log of the fax transmission process. The following failures cannot be fixed in HP-UX (or cables or a new modem, etc):

- wrong phone number
- wrong area code
- did not dial 8 or 9 for outside line
- dialed 8 or 9 but it's not required
- dial 1 but not needed
- did not dial 1 but it is needed
- receiving fax is busy (but fax software should hanlde this)
- receiving fax jams during reception/printing
- receiving fax is a computer which ran out of space or rebooted or other problems

If your fax software doesn't provide this information in a detailed log, find another fax software vendor.

[Fred Martin_1]

Thanks Bill, I'm sure it's none of those. A department here uses this fax daily to send faxes to 10-15 vendors. Fails equally (about 30%) to all of the vendors fax machines.

Fred

[Fred Martin_1]

The fax software just issues a general 'transmission error' message. I ran tests with a machine local to me, and the machine takes the call and answers, goes through the handshake, then fails.
Fred

[Bill Hassell]

This may as simple as a bad fax modem. I used to run a 4 modem fax pool with MultiTech modems and got similar errors with the fax software I had but only on one modem. Try another one.

[TwoProc]

Over the years, I've found that faxes, modems, and printers are all there mainly to make sys admins maintain their humility...

And I hate them all for it.

:-)

Remember, true humility only comes from professional humiliation.

[Fred Martin_1]

Yeah, swapping the modem was one of the first things I tried. Cables too. Well, I've more or less decided that the fax software itself is screwed up. While troubleshooting this morning I stopped the fax services and now they won't start up again. Says the fax server is already up when I issue the command to bring it up. When I query the status of server though it says it's down. A catch 22.

I have a window tonight where I can reboot the whole dang unix box, I may just do that. A sledge hammer, I know. But then I'll know.

Fred

[Patrick Wallek]

Have you checked for rogue fax software processes with 'ps -ef'? What fax software are you using?

[Fred Martin_1]

Yeah I scoured 'ps -ef' pretty carefully. I'm using VSI-Fax, and a very old version of it at that, ver.3 - I think another company owns them now and they're on ver.6, I've not paid for support in a long time.

[TwoProc]

Fred, there's probably a lock file somewhere that's making the software think it's up. It may be even named something as obvious as SYSTEMUP, OR LOCKID, or LOCKPID... etc. Usually they are zero bytes and you can just delete them, move them, rename them, etc. what ever you feel comfortable about.

[Dennis Handly]

>TwoProc: there's probably a lock file somewhere

Running tusc will quickly tell you what opens/stats are being done.

[Fred Martin_1]

I found the command-line utilities for the VSI-Fax software, one that allow you to test the modem with AT commands and so on. I can connect to /dev/ttyd2a1just fine, force it to dial, etc. etc. so I no longer believe this is an issue with that.

I'm convinced now it is related to the fax software itself, and will pursue that.

Lock file - that does seem likely, I'm looking for it. VSI-Fax also maintains a database which might be hosed. I have plenty to look at.

Thanks all for the assistance.

[TwoProc]

Dennis,

That's good advice too, but what I was talking about was left over lock files after the program died/waskilled/crashed - tusc wouldn't show that, unless remnants of the program were still up.

[Bill Hassell]

I used VSI-Fax for several years (mid-90's) at HP, probably the same version you are using. I did have problems with VSI-Fax support, especially with the character mode menu and HP terminals. We mostly faxed out and the occasional failures were redone with a paper fax. I didn't try to track failure modes such as the type of fax machine on the other end.

I suspect that both the MultiTech modem as well as the controlling software may be the issue. I'm sure better communications methods have been designed into new fax machines -- the software may have been improved too. I would see if you can get a trial version of the latest VSIfax software.

[Fred Martin_1]

In fact, I've been trying to convince the department to use another method - the database they use can email docs as PDFs and I'd rather they do that.

I have a windows-based fax server for the rest of the company but these folks can't use it due to the format particular documents they send. But if I can get them to use email I can retire this older VSI-Fax stuff.

Thanks again.

[Dennis Handly]

>TwoProc: what I was talking about was left over lock files after the program died/waskilled/crashed - tusc wouldn't show that

Sure it will. When you restart, it has to open and or stat that file and tusc will show those syscalls.