AS5300 in POS environment

We have a AS5300 loaded with MICA modems and 4xT1 card. POS terminals dialup to the AS5300 and fork a telnet stream to a host target HOST_A on a specific port. Here is a snippet of how my lines are configured

ip host HOST_A 1075 192.168.1.2 ! ! modemcap entry POS_TERMINAL:MSC=&F&D2S0=0S15=0S21=0S22=0S23=0S24=0S29=4S30=2400S31=1200S52 =0S53=0S54=32968S64=10 ! ! line 1 48 no motd-banner no exec-banner exec-timeout 0 0 no flush-at-activation no vacant-message modem InOut modem autoconfigure type POS_TERMINAL autocommand telnet HOST_A /stream /noecho /quiet no activation-character transport input all transport output all escape-character NONE

My problem is that the AS5300 sends several extra DEL (Delete) characters which cause the POS terminal to reject transactions. Below is the output of a capture from a RS232 protocol analyzer

Data received: OK Data received: OK Data received: OK Data received: OK Data received: OK Data received: CONNECT38400/NONE/1200 Data received: Data received: Data received: Data received: Data received: Data received: Data received: Data received: Data received: Data received: Data received: | Data received: Data received: XXXXXXXXXX0000090000003600182 Data received:

5$0.3600 00@ Data received: Data received: c?

I believe these delete characters are part of the telnet protocol specs, but I could be wrong, because the "stream" option should send the data in a raw tcp stream. Anybody have any ideas on how to remove the extra DEL characters from the stream or maybe there is another way to do this without using the "modem autoconfigure" option.

Reply to
Matteo
Loading thread data ...

Matteo,

If you are seeing the extra DEL characters, then maybe your problem is that HOST_A is configured for TELNET, but your client side is configured not to do TELNET (telnet /stream). So the TELNET IAC characters (ASCII

255) be seen as DEL (ASCII 127) once the high bit is cleared.

You can see this from the router side by trying a "telnet /debug" to your host and seeing if we receive any TELNET negotiations.

If the host is sending TELNET, then remove the /stream from the client side.

If the host is frontended by an IOS milking machine, then you should TELNET to the stream-range TCP ports (4000+port or 5000+rotary) rather than to TELNET-range TCP ports.

You can see what the router is sending on the modem link with the following hidden debugs:

router(config)#service internal

(busy out all modems but 1/0)

debug modem mica tx [rx] 1/0

Some comments on your config:

  1. for a PoS or *any* character mode application, always configure "flush-at-activation". Otherwise a call will likely receive some junk that's lying around in the input buffer.

  1. Your modemcap is extremely long. Modem autoconfigure in some versions can have problems with a modemcap string longer than about

50 chars. I would recommend tightening this up. Try this:

modemcap entry POS_TERMINAL:MSC=&F&D2S0=0S29=4S21=0S22=0S23=0S24=0

Regards,

Aaron

Reply to
Aaron Leonard

Hi Aaron, I tried your test telnet HOST_A /debug and confirmed that HOST_A is not in telnet modem. What did help a bit is the shorted INIT string as you suggested. With this INIT string the deletes seem to be part of the connect message sent by the MICA modems.

Data received: CONNECT38400/NONE/2400 Data received: Data received:

********00002200003122001857122$31.220000Q Data received: Data received: F??wwwwwww Data received: NOCARRIER

Is there a way to set the modems in quite mode so that it doesn't send the connect message? Maybe this will remove the extra delete characters.

Reply to
Matteo

Matteo,

The CONNECT string is sent by a modem to its local DTE. If you have this:

[AS5300 [MICA]]---pstn---[PoS modem]=[PoS terminal]

and have the PoS terminal placing the call, then when the modems train, the PoS modem will send its CONNECT string towards the PoS terminal, and MICA will send its CONNECT string towards the router.

You can cause MICA not to send a CONNECT string when answering calls (probably a good idea) with Q2, see

formatting link
However, the CONNECT string sent by MICA will be discarded (because it is sent prior to the logical DSR up event on the MICA line), unless you have "no flush-at-activation" configured. (Always a bad idea to have "no flush-at-activation" configured if doing PoS.) In any case, the MICA CONNECT string is sent in the router direction, not towards the originate modem.

Furthermore, I don't see "CONNECT 38400/NONE/2400" as being anything that MICA will send. 38400 bps is a DTE not DCE rate, and MICA only ever sends DCE rates not DTE rates. This message must be emanating from the local PoS modem.

Regards,

Aaron

Reply to
Aaron Leonard

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.