translate x25 to tcp

[casablancag]

Hi we need to translate x25 packets to a tcp stream. The translation works fine but our electronic payment terminal application has problem with the received data stream from the router. Our router sends in front of the application data a 4 byte QBit packet which our application cannot handle. Is there a way to disable this router behaviour ?

Output of the x25 debug

tpkg29#

Apr 26 10:57:44.417: Serial2/0: X.25 I R1 Call (20) 8 lci 1

Apr 26 10:57:44.417: From (8): 46437037 To (9): 464113482

Apr 26 10:57:44.417: Facilities: (6)

Apr 26 10:57:44.417: Packet sizes: 128 128

Apr 26 10:57:44.417: Window sizes: 2 2

Apr 26 10:57:44.417: Serial2/0: X.25 O R1 Call Confirm (3) 8 lci 1

Apr 26 10:57:44.685: Serial2/0: X.25 I D1 Data (63) 8 lci 1 PS 0 PR 0

Apr 26 10:57:44.685: Serial2/0: X.25 O D1 RR (3) 8 lci 1 PR 1

Apr 26 10:57:45.025: Serial2/0: X.25 O D1 Data (4) Q 8 lci 1 PS 0 PR 1

Apr 26 10:57:45.025: Serial2/0: X.25 O D1 Data (37) 8 lci 1 PS 1 PR 1

Apr 26 10:57:45.041: Serial2/0: X.25 I D1 RR (3) 8 lci 1 PR 1

Apr 26 10:57:45.053: Serial2/0: X.25 I D1 RR (3) 8 lci 1 PR 2

[ebreniz]

Could you try the translate command with a keyword quiet at the end

translate tcp 192.16.x.x port 2200 stream x25 < > quiet

or

x29 inviteclear-time none

[chris.lott]

Hello,

I have the same issue as the OP and also have the configuration suggested in the reply, x29 inviteclear-time none (and also x29 inviteclear-time 5) with no joy.

I too am sending data over TCP and having it translated by the cisco 2901 and sent out of Serial0/0/0 over X25

the CLEAR command is never transmitted, instead the bank wait 25 seconds and then clear the line. This needlessly retains the x25 line making it unusable for 25 seconds.

How can I get the x25 line cleared from my end once the transaction has concluded (as seen by 11:37:35.456).

Dec  6 11:37:31.320: Serial0/0/0: X.25 O D1 Data (66) 8 lci 1024 PS 1 PR 0

Dec  6 11:37:31.332: Serial0/0/0: X.25 I D1 RR (3) 8 lci 1024 PR 1

Dec  6 11:37:31.336: Serial0/0/0: X.25 I D1 RR (3) 8 lci 1024 PR 2

Dec  6 11:37:35.456: Serial0/0/0: X.25 I D1 Data (128) 8 lci 1024 PS 0 PR 2

Dec  6 11:37:35.456: Serial0/0/0: X.25 O D1 RR (3) 8 lci 1024 PR 1

Dec  6 11:38:00.324: Serial0/0/0: X.25 I R1 Clear (5) 8 lci 1024

Dec  6 11:38:00.324:   Cause 0, Diag 0 (DTE originated/No additional information)

Dec  6 11:38:00.324: Serial0/0/0: X.25 O R1 Clear Confirm (3) 8 lci 1024

[paolo bevilacqua]

Can you prove that TCP has closed, hence need to close SVC too ?

[chris.lott]

Hi Paolo,

The vty session sits idle and so does the x25 session.

The application has had all the data and moves on, noting else is transmitted on the TCP side.

It's as if the router has not understood the CLEAR command and therefore not passed it to the x25.

Many thanks

Chris

[paolo bevilacqua]

Clear in X,25 means SVC teardown, or 'call clear', ot hang-up.

If router does not receives 'FIN', meaning session close, on the TCP side, it will not send clear on the X.25 side.

Then if the other side wants to clear on a timeout, router can';t do anything about.

[chris.lott]

As it is the TCP side that we want to initiate the teardown, do you think the router is not getting a FIN ?

I am lead to believe there may be a configuration command we are missing, similar to x29 inviteclear-time.

When x25 side send the clear after 25 seconds the sessions are ended, we just need the TCP to do the clear to prevent 25 wasted sesonds where the line is being 'blocked'

[paolo bevilacqua]

As above:

You need to prove that router is receving TCP close, but not translating to X.25 clear. That is easily done taking debugs.

[chris.lott]

Wha we get is as follows (SVR= the Server, RTR is the Router receiving IP and transmitting via X25)

SVR - RTR SYN

RTR - SVR SYN-ACK

SVR - RTR ACK

SVR - RTR PSH-ACK

RTR - SVR ACK

RTR - SVR PSH-ACK

SVR - RTR FIN-ACK

RTR - SVR ACK

25 Second pause (the next action is because the X25 has been shutdown by the Bank to prevent line hogging)

RTR - SVR FIN-PSH-ACK

SVR - RTR ACK

[chris.lott]

This issue was found to be caused by the new routers having a latest version of IOS which has a bug.

Using an old router with really old IOS worked as expected, translating the FIN and closing the x25 line withing 1 second.

Fix scheduled for Aug 2013 in IOS 15.3(2)T1