I send this email to Eicon:
I am experiencing a problem with the X.25 S91 Eicon card. This problem prevents the S91 being used to emulate remote sites calling in. This is part of our test scenario for the new host.
I have been using a pair of S91 over the last month, emulating a X.25 host and random remote stations. Several million packets have been sent / received, and the test environment has been stable.
The specific problem:
One S91 is configured with no circuits enabled. That is no calls to x25xlisten are pending. (The card may be either a DTE or DCE.)
A second S91 makes a x25call, with 14 character remote, and 14 character local NUA’s. The fast select mode is enabled:
x25data_facility_.xd_data[0] = 0x01; // fast select
*(BYTE*)&x25data_facility_.xd_data[1] = 0x80; // no reverse charging.
x25data_facility_.xd_len = 2;
The x25data_U_.xd_len field is set to 128.
I call x25xcall().
When the completion call back arrives:
x25doneinfo has the following:
xi_buf[0] has 0x11
xi_buf[1] has 0x00
The xi_retcode is 144 "Modem Not Ready". ( Sometimes ENETPKTLNR
"Packet level not ready")
If I change the senario: by reducing the x25data_U_.xd_len field to 120 or less, or reduce the remote NUA to 11 chars:
I now get the xi_retcode as ENETUCALL, (Unsuccessful call.) This is the correct operation!
Can you re-create this bug? Is there a realistic solution?
Conclusion:
This bug prevents the S91 being used to emulate sites calling in. We do have S50’s running live that do successfully receive fast select 128 byte data calls.
Until we connect a S91 to a live feed, we cannot be sure.
We’ll wait for Eicon to reply, but we may have to get a Cisco, at least to complete testing.
This email does trigger a prompt response from Eicon - but they cannot recreate the problem.
I hack one of their samples, and email it to them.
Thank you for your prompt response!
I am attaching a "hacked" eicon sample "filetxfr" that exhibits my reported fault on fast select with NUA's. Both source and runtime are zipped.
Please inspect CX25SendFile::Send(int)
You will see that this has a parameter that sets the user data length. The local and remote NUA are set to arbitary numbers of size 14 digits.
I've changed the sample app "filetxfr" /c parameter to set the user data size.
In the test lab, I have two S91 cards back to back in separate pc's, running Windows 2000
Here is a cut and paste of me playing with the app:
| C:\eicon_hack>filetxfr /p 1 /c 120 Eiconcard X25 Development Tools for Win32 Build 214 Copyright(c) Eicon Networks 2001. All Rights Reserved. Thread created. Error: b0 Cause: ee Diag: 12 C:\eicon_hack>filetxfr /p 1 /c 12 Eiconcard X25 Development Tools for Win32 Build 214 Copyright(c) Eicon Networks 2001. All Rights Reserved. Thread created. Error: 12 Cause: 0 Diag: 40 C:\eicon_hack>filetxfr /p 1 /c 128 Eiconcard X25 Development Tools for Win32 Build 214 Copyright(c) Eicon Networks 2001. All Rights Reserved. Thread created. Error: 90 Cause: 11 Diag: 0 C:\eicon_hack>filetxfr /p 1 /c 128 Eiconcard X25 Development Tools for Win32 Build 214 Copyright(c) Eicon Networks 2001. All Rights Reserved. Thread created. Error: b2 Cause: 5 Diag: 0 |
You can experiment with the size - Anything greater than 120 bytes we get erratic
errors.
I look forward to your comments, and a fix!
This email triggers a prompt response from Eicon, and they can reproduce the bug!
The engineer said that "there was an official release of build 214 a few months ago." I have not seen it!
http://www.eicon.com/develop/tools/x25/download.htm still has build 210.
Using Ex25.dll, build 214, has no effect on my bug.
5/10/01 - await progress....
... and the answer is to increase the packet size from 128 to 256 using their configuration program. Hmmmm.