Search our site   

Downloads

Cables

Register

Documentation

FAQ's

Home

Site Map

 

 

The Software Group Limited FAQs

Raw Sync FAQ

X.25 FAQ


SGP FAQ


 

Raw Sync FAQ

Q. Why do I get the following unresolved externals when compiling a raw synchronous application under Wanware NT?

Linking...
  • testapp.obj : error LNK2001: unresolved external symbol _sync_lookinit
  • testapp.obj : error LNK2001: unresolved external symbol _sync_lookclose
  • testapp.obj : error LNK2001: unresolved external symbol _sync_close
  • testapp.obj : error LNK2001: unresolved external symbol _sync_errorstr
  • testapp.obj : error LNK2001: unresolved external symbol _sync_looksel
  • ..\..\bin\Debug\testapp.dll : fatal error LNK1120: 5 unresolved externals

  • A. You need to define WINNT, either by putting "#define WINNT" in your source file before including libsync.h, or by putting "-DWINNT" in your makefile.


    X.25 FAQ

    Q. Why do I not get an indication of link failure when I disconnect the cable from the X.25 adapter?

    A. Detection of link failure is a function of the T1 and T3 timers as well as the N2 counter. These are defaulted to 3, 0, and 10 respectively. If T3 is 0 then the link layer will not report to the packet layer when the link is down. To detect a link down condition you need to set the T3 timer to a non zero value.

    You should not set this value less than the value used for T1, since too low a value will cause the link layer to report a link down condition due to normal delays on the line. Once T3 is set to a non zero value then a link down condition will be reported after T1*N2 seconds.

    Also, there is a case where the value of the T3 timer is irrelevent and that is when there is data outstanding to be acknowledged on the line. In this case, we will wait for an RR (receiver ready) from the remote and if we don't get it, we will try again T1 seconds later up to N2 times. If there is NO data outstanding to be acknowldged then we will only detect the link down condition if T3 is set to a non-zero value.

    You can change the values of the N2 counter and the T1 timer but you should not change the value of the T1 timer to a value less than the time required to transmit the longest packet based on the speed of the link. The longest packet is defined by N1 parameter.


    Q. Why is the remote side of my X.25 link clearing my calls?

    A. There are many reasons why the remote might clear your calls. You can use the tracing utility (tsgtrace) to view the cause and diagnostic codes generated from the Clear. The tsgtrace utility will give these as hex valuesalong with a translated meaning. Note that the translated meaning is only relevent on received clears if the value is less than hex 80. The reason for this is that received diagnostic bytes >= x80 are user-defined and as such they only have meaning to the party transmitting them. We will translate them to what our interpretation of the value is but that will likely not be the same meaning as the transmitting party intended. Values less than x80 are defined by the CCITT and have the same meaning to everyone.

    The online documentation that came with your TSG product lists cause and diagnostic bytes and their meanings. Below are some of the more commmon reasons for received call clears:

    • Diag: x31 or x32: T21 or T23 timer expiry
    • – the most common cause for this diagnostic is a mismatch with the number of LCI (logical channels) configured between your end and the remote. If you are using SVC's (switched virtual circuits) then check your link configuration parameter (bwc_num), which indicates the total number of both-way SVC's used. This number should match the number of channels allocated for you by your X.25 network provider. If your X.25 network provider has less LCI's configured then your calls could be cleared.
    • Diag x43: Invalid Called Address
    • – means that the dna address you have provided in your call is incorrect. In many cases, you do not need to provide the dna (X.25 address) in your Call Request but this value is filled in by the X.25 network provider but if you do fill in the dna yourself, be sure that you use the correct value; otherwise, the call will be cleared.
    • Diag: x46 Incoming Call barred
    • – indicates the call was barred. This problem can occur if you are trying to access a machine in a CUG (closed user group) and you are not a member of the group. If you are calling a Hunt Group, then you will need to set the "clam" parameter in your link configuration file to "YES" to prevent re-directed calls from being cleared.
    • Diag x41: Invalid Facility
    • – indicates an invalid facility in the call setup packet which likely means that one or more facilities are enabled when they should be disabled or visa-versa. Try toggling each of the following facilities:
      • Packet Size Negotiation (link configuration parameter: packet_neg)
      • Window Size Negotiation (link configuration parameter: window_neg)
      • Class Size Negotiation (link configuration parameter: class_neg)

      These values are all defaulted to "YES" by default, which means that we will try to negotiate packet size, window size and class size with the remote but if you have not subscribed to these facilities with your X.25 network provider, then your calls will be cleared with diagnostic x41.

      – If you use Datapac as your X.25 network provider, then you may need to set the link configuration parameter "force_negotiate" to "NO"

    • Diag x42: Invalid Facility Value
    • – indicates an invalid value for a facility parameter which means that either the window size, packet size or throughput class is different than what the network has configured for you.
      – you will need to find out from your network provider what values are being used for window size, packet size and throughput class.
      – to get running right away, try using a packetsize of 128 and window size of 2 (these should work for most X.25 networks). You can also try using a class to 10 (9600) which should also work for most X.25 networks.

    Q. Why am I getting "unconfigured logical channel" shown on tsgtrace when I receive an incoming call?
    A. TSG uses a default of 8 logical channels for it's X.25 software. If a call is received on a channel number greater than 8 then you will see an "unconfigured logical channel" error. To change the number of logical channels used, modify the bwc_num parameter. Note that you will need to restart the protocol stack after doing this. How to do this depends on what product you have; eg,
    Wanware Linux:
    "/etc/wanware restart"
    Wanware NT:
    double-click on the "WAN Protocol Service" in Wanwizard to tear down the X.25 stack then double-click again so restart the stack
    NetcomII:
    "/etc/x25net restart"


    Q. What is netid?

    A. The netid is simply a reference to a board/link combination. For example, if you are using a 2-port X.25 adapter then:

    netid0 references: board0 link0
    netid1 references: board0 link1
    netid2 references: board1 link0
    netid3 references: board1 link1
    etc ...

    You can see this relationship between netid and adapter/port by looking at the "packetnets" file in the /etc directory for NetcomII and Wanware Linux.


    Q. How can I increase the number of VC's available to NetcomII or Wanware Linux?

    A. Let's assume that you want to use 128 VC's per link:

    1. Change the value of the PKTVCNS parameter in
    2. /etc/conf/pack.d/x25pkt/space.c (NetcomII)
      /etc/wanware_modules (WanwareLinux)
      to indicate the number of VC's you want to use per link. In this example, you would change the value of PKTVCNS to 128.
    3. Rebuild the kernel (NetcomII only) and reboot after changing the value of PKTVCNS.


    4. Change the value of bwc_num to 128 in your link configuration files. You can change the number of both-way channels to 128 by either using the /etc/tsgconfig utility or by editing the link files directly. The link files are kept in /usr/lib/x25/config and are called link0, link1, etc. After making this change run either "/etc/x25net restart" (for NetcomII) or "/etc/wanware restart" (for Wanware Linux) to rebuild the X.25 protocol stack.


    Q. Why am I seeing error: "attaching to PVC .. not a pvc" when using PVC's (permanent virtual circuits)?

    A. This is most likely due to a configuration problem. Check to see if you have defined PVC's in your link configuration file. The parameter "numpvcs" should be set to the number of PVC's used. Also, you will need to modify your SVC configuration as well when using PVC's. If you will not be using SVC's at all then set the bwc_num parameter to 0. If you will be using both SVC's and PVC's then set the bwc_first parameter to one higher than the number of PVC's defined. Note: You will need to rebuild the protocol stack after doing this.

    There are also other reasons why this error might be occuring. If you have written an application using our X.25 API, then the following reasons could also cause this error:

    – you issue X25clear on a ct which corresponds to a PVC or HDLC link
    – you issue the attach and the lci is 0 or greater than 4095
    – you issue a detach on a ct which corresponds to an SVC
    – packetnets file should have TYPE LAPB, not TYPE X25

    Q. What is causing the error "X.25 open netid 0 failed: Unable to look up Network ID" when I try to run my X.25 application?

    A. This is most likely due to a configuration problem. Check to see if you have defined PVC's in your link configuration file. The parameter "numpvcs" should be set to the number of PVC's used. Also, you will need to modify your SVC configuration as well when using PVC's. If you will not be using SVC's at all then set the bwc_num parameter to 0. If you will be using both SVC's and PVC's then set the bwc_first parameter to one higher than the number of PVC's defined. Note: You will need to rebuild the protocol stack after doing this.


    Q. Why does x25error return 13 (Bad Default) when using the X25listen function in the X.25 API in Wanware Linux?

    A. There can be only one default listener in the system and normally that's the x25daemon. If you want your application to be the default, you have to tell x25daemon not to do a default listen. You can do this by adding "-n" to the startup of x25daemon in /etc/wanware.

    Q. I can't get incoming calls to go to login in Wanware Linux?
    A. This cannot be done in Wanware Linux since Linux does not contain a character-based tty line discipline inherent in the OS but instead uses a streams-based tty interface which we don't support. You can; however, use xfft (xpad -uFILE) for file transfer across X.25 since xfft is an application written using the X.25 API. That is, you can startup any application on Wanware Linux as long as it's an API application but you cannot write an API application to invoke login, since getty and login expect to talk to tty drivers.

    Q. Why is my X.25 application returning X25BADPID (error 12 - Bad Protocol ID) on X25listen()?

    A. This can occur if there is already an existing listener on that protocol ID. When an application does a listen for incoming calls, it tells the library and stack what the first byte of call user data should be for calls that the application is interested and this error indicates the indicated protocol ID is bad.

    Why is the protocol ID bad? Either the old instance of the program that you were shutting down had not exited yet (the close of the underlying X.25 device would result in the old listen stopping) or there is some other program in the system listening on the same protocol ID.


    Q. Why are incoming calls being cleared with diagnostic 0x9F (no listener)?

    A. This problem can occur if you are not using the x25daemon to listen for calls but are instead using your own application and you have started the x25daemon using the -n argument (x25daemon -n). If you are not running the application as user "root" then check the permissions on the /etc/packetnets file. If the permissions are set to not allow the application user access, then X25open() will fail as the application will not be able to open the /etc/packetnets file to find the netid.

    Q. Is there a way to configure NetcomII to act as a passive line monitor?

    A. No, our X.25 library was not designed to monitor frames without doing a connect on a protocol level. You need to use a protocol analyzer for this purpose.


    Q. We are writing an application using the NetcomII API to connect to an X.25 network that is using subaddressing. Do I need to treat subaddresses in some special way?

    A. In the X.25 protocol, there is no delimiter between the base address and subaddress. Therefore; you can configure the number of digits to use for each (see called_length parameter /usr/lib/x25/config/net.defaults). Essentially, you can decide how many digits you want to use for subaddress then it's up to whatever is parsing the address to look at called_DNA in the callprog structure (or in the parse fields of /etc/x25incalls if our daemon is parsing the incoming call).

    SGP FAQ

    Q. How can I tell if there is an IRQ conflict between the SGP and another device in the system on Wanware Linux?

    A. The I/O and memory range used by the SGP is assigned by the BIOS at system boot time and should not conflict with any other device. The /var/log/messages file will indicate the memory and I/O address given by the BIOS. Memory addresses are near the 4Gig range so that the SGP does not conflict with system memory. Note that the all of the resources used by the various PCI cards are set by the BIOS each time the machine boots. To see what IRQ is being used by the SGP, look in /proc/pci. You then need to make sure that any newly added com port or other device is not using the same IRQ value.

    To see if the SGP is actually getting interrupts on the IRQ given in/proc/pci, look at the /proc/interrupts file. If this file contains an entry for "SGP", then the SGP is getting interrupts. If "SGP" is not in the /proc/pci file then the SGP is not getting interrupts which indicates it'sprobably conflicting with another device.


    Q. Does the SGP support RS-422?

    A. To answer this you need to know what type of physical connector is required. The reason is that RS-422 isn't a complete specification for defining an electrical interface. The SGP supports the following electrical interfaces on RS-422:

    RS422 on a DB25 connector = EIA530
    RS422 on a DB37 connector = RS449
    RS422 on a DB15 connector = X.21