using Acceleport RAS 8 with 'mgetty' application

USB Devices
1

Hi everyone,

I’ve installed an Acceleport RAS 8 card in a Sun PCI-based machine which is used as a dial-up access server for the non-profit ISP I’m involved with.

Up to now we’ve used standalone analog modem banks connected to Magma serial port cards.

We use the ‘mgetty+sendfax’ application available from:

http://alpha.greenie.net/mgetty/

to manage the dial-in ports. I’d like to use this with the RAS card but so far it’s resulted in partial success, but each modem on the RAS card gets locked in a busy state and the machine needs a reboot to get the RAS card ready to answer more calls.

‘mgetty’ works by ‘listening’ for ‘RING’ messages from modems, then enabling auto-answer, then waiting for the ‘CARRIER xxxx’ message. I’m assuming this method will still work with modems on the RAS card as they appear to behave just like regular modems in terms of how they communicate with host software applications.

The modem init string used for the standalone analog modem banks is ‘ATS0=0Q0&D3&C1’ which turns off auto-answer in anticipation of the ‘RING’ message once a remote modem calls the respective number to set up a data connection.

Will this init string cause problems for the RAS card modems? Should it be modified to ensure that the RAS card modems are not going to stay in a ‘busy’ state after a call is terminated?

That’s what appears to be happening. I’ve tried using ‘digiras_reset’ to reset modems seperately, and reset all modems, with no change in the busy state of the RAS card modems. If I test it out by calling one of the numbers, the ISDN NT1+ which provides the analog lines shows it’s ‘sync’ LED coming on to indicate traffic on the D channel, but after about 10 seconds the busy tone is heard so the RAS card is deciding that the relevant modem is busy.

One other possibility, and I’m sure this is a factor, is that the RAS card is not one of the parts marked as being suitable for Australia. It’s coming up with a list of Asian countries when I try and set the modem identity. The modem identity is presently set to ‘Singapore’. If this is likely to be a a cause of the problem I’ll have to find one of the RAS cards suitable for Australia…

Tips, advice, etc. would be gratefully received… :sunglasses:

Regards,

Craig.

2

Do the lines show “BUSY” if you connect to the modem directly (no mgetty running)? This can be done by using the ‘cu’ command (included in the uucp package):

chown uucp:uucp /dev/ttyG*
cu -l ttyG#_## -s 115200

Call the number, then type ‘ata’ once the word RING appears.

If this works, you may want to add the debug flag to your mgetty entry to try and determine the cause of the busy behavior when used with mgetty (/sbin/mgetty -x9).

3

I don’t see any problems with your AT command init string. Basically its ensuring that DCD acts naturally, result codes enabled (so it can see the RING message), and that the modem doesn’t automatically answer on its own. The &D3 command is a soft reset on DTR drop command, which isn’t a bad thing.

Here is a link to the mgetty+sendfax page:

http://home.leo.org/~doering/mgetty/mgetty_toc.html

The Acceleport RAS would most closely resemble the “Rockwell-based modems” description on that page.

As far as the modem getting locked in a busy state, this might be a result of a flow control mismatch. I believe by default, mgetty+sendfax uses hardware (RTS/CTS) flow control. Check flow control on the port with the following command:

ditty -a /dev/ttyG0_00 (or another device, as appropriate)

In the output, -ixon -ixany -ixoff, and either rtspace ctspace or crtscts should all be set in order to disable software and enable hardware flow control.

Some command-line options you may be interested in to perform various functions on the modem:

Hangup: dm_admin -b0 -p1 -c1 -h (to hangup channel 1 of board 1)

Cold Reset: dm_admin -b0 -p1 -c1 -r (to reset channel 1 of board 1)

For more info on dm_admin options, please refer to the dm_admin man page.

4

Ok, I’ve just extracted the parameters of one modem using ‘ditty’, and this is what it says:

ditty -a /dev/cua/dgrasa01

onstr offstr term
maxcps 100 maxchar 50 bufsize 100
-forcedcd -altpin -fastbaud (115200) -printer edelay (0)
eia232 -rtspace -dtrpace -ctspace -dsrpace -dcdpace
DTR+ RTS+ CTS+ CD- DSR+ RI-
speed 115200 baud;
rows = 0; columns = 0; ypixels = 0; xpixels = 0;
csdata ?
eucw 1:0:0:0, scrw 1:0:0:0
min = 1; time = 0;
intr = ^c; quit = ^; erase = ^?; kill = ^u;
eof = ^a; eol = ; eol2 = ; swtch = ;
start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
-parenb -parodd cs8 -cstopb hupcl cread clocal -loblk -crtscts -crtsxoff -parext
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -iuclc
-ixon -ixany -ixoff -imaxbel
-isig -icanon -xcase -echo -echoe -echok -echonl -noflsh
-tostop -echoctl -echoprt -echoke -defecho -flusho -pendin -iexten
-opost -olcuc -onlcr -ocrnl -onocr -onlret -ofill -ofdel
-rtsxoff -ctsxon -dtrxoff -cdxon -isxoff xcibrg rcibrg tsetcoff rsetcoff

I reconfigured mgetty last night to use a new command string which sets more things than the previous one:

AT&FE0S0=0Q0V1W2X4&D3&C1&K3

The &F resets the modem to ‘factory defaults’. &K3 sets hardware flow control.

However, the modems have all stayed busy after the first incoming call ended.

I’ve got mgetty configured to use hardware flow control as well using:

#define DATA_FLOW FLOW_HARD

The only thing I haven’t looked at changing is the modem type. At the moment I have the default modem type configured as ‘auto’ but I will probably change this to ‘data’ since the modems are being used for indial data connections only.

Craig.

5

In your ditty -a output, all flow control is turned off. Software flow control (-ixon -ixany -ixoff) being turned off is a good thing when talking about a modem, but you would definitely want hardware flow control turned on.

Reboot the server, then send “ditty rtspace ctspace /dev/cua/dgrasa01” from the command line, then retest your application. You can use ditty -a to confirm the settings have been made.

Another thing that is sometimes the source of lockups is contention with another PCI card. Trying the card in a different PCI slot or changing the order of PCI cards on the bus and seeing if you get the same behavior would be a good troubleshooting step as well.

6

Ok, I manually set the ‘rtspace’ and ‘ctspace’ options using ‘ditty’ for one port and the options have ‘stuck’.

I’ll need to create a script which manually sets port options and that should take care of the flow-control settings for all 8 ports on the card at boot time.

I’m using Solaris PPP (which in Solaris 9 is Sun’s rework of the Paul Mackerras PPP code), with PPP options set in files stored in /etc/ppp.

I already have the ‘crtscts’ setting in the master PPP options file, so shouldn’t that cause the RAS drivers to set up hardware flow control when a PPP session is started in response to an incoming call detected by Mgetty as a PPP login?

If it proves that Mgetty itself is the problem, I can reconfigure the system, but the dial-in server suppports members using PPP, shell and UUCP logins. I don’t dedicate ports to specific session types (which is the reason I’m use ‘mgetty’ as it auto-detects the desired session type based on the username presented and whether or not LCP packets are sent from the remote system).

Craig.

7

I’d recommend creating a startup script called /etc/rc2.d/S99digi, and adding your flow control strings there. This way, the settings will be made at startup and available for any application, not just ppp.

8

Thanks for that Michael. I haven’t looked at the problem for quite a while now (been busy with other things), but the ongoing issues with the RAS card are bugging me again. :sunglasses:

I’ll look at the scripts in /etc/init.d and examine what can be done to hard-code the flow-control settings and with luck that could solve the problems of modems sitting in busy mode all the time.

Just today I tried calling some of the lines connected to the RAS card and three of the four lines I had hooked up to it returned a busy signal when called from a normal phone, while one answered and started going through the training sequence.

Craig.

9

If you’re still having problems with the RAS card, my recommendation would be to call Technical Support at this point.

10

Craig,

Did you ever resolve this issue? Having the same exact issue with RH ES 3.0 and acceleport RAS 8. Cannot get modems to hang up after initial call. We even thought that our modem was defective (It would not work on Windows 2000) So we exchanged it for a new acceleport - still doing the same thing.

Kevin

11

I’m also having exactly the same problem on SuSE 9.1, with a RAS 8 PCI. I have tried two of these boards, both of which behave in exactly the same manner. I wonder if anybody has had any joy with these things?

12

I have found this to only a problem when using mgetty. When using Minicom, UUCP, and agetty everything works great.

What I find interesting, is it appears to work in Debian for some reason, using the same version of mgetty? I’m trying to pursue this to see what could be different in this Distribution that causes mgetty to work and hang up the phone line.

13

Agetty, never come across that one. I’ll seek it out and post as to how I get on.

14

I believe I found a solution to force mgetty to hang up the line. These adapters use Rockwell chipsets, when using the recommended init-string, mgetty recognized DCD as high and forced a hang-up. Here are the lines added to /etc/mgetty+sendfax/mgetty.config

port ttyG0_03
init-chat “” \d\d\d+++\d\d\dATQ0V1E0 OK AT&S0&D2&K3S0=0 OK

15

I think you’re the man!!

I just tried it and it seems to have done the trick, well done!

I was just in the process of writing up a diary of the last few days I’ve spent trying to get this thing working to send to Digi and to the mgetty mail list. The frustrating thing is that I’ve a crummy old USR Sportster sitting under my desk which worked at the first time of asking, yet you shell out for a so called professional piece of kit and the thing doesn’t appear to behave the way it should - still never mind we can move on now and do all the other stuff.

Cheers, once again!!

16

If you’re still having problems with the RAS card, my recommendation would be to call Technical Support at this point.

WoW gold|Diablo 3 Gold|kaufen Guild Wars 2 gold