Mail a friend
 Print this page
 Add to favorites

The NexGen Software makefile does not work. What could be wrong?

Ensure you are using gmake. The version 3.77 is fine expect for cygwin (use make instead).

Recall that all dependencies to DOS shell commands must be removed from makefiles.
For instance the del command must not be directly called from the rules of makefiles. They can be called through the variable $(RM) instead.

It could also be a win98 / win2000 compatibility issue.
So try to compile on the other system if possible.
For instance, it could be an echo commands that fails on win98 if its argument string exceeds something like 256 char.

The error in makefile might also actually comes from the compiler or the linker you are using (the makefile is not actually incorrect).
For instance, if you don't have an up-to-date licence file, or if you forgot to plug a required dongle, some compiler/linker might generate an error more or less reflecting the problem.
Another thing to know: the keil compiler produces a link error on win98 systems if paths are too long (you can use subst command to shorter them).
I have built an executable using NexGen Software libraries that does not work once executed. Any checklist to start with?

Here are a couple of points that you might like to check:

  • If not already used, try to enable NexGenOS debug facility to identify the reason of failure. NexGenOS has a built-in debug facility (cf. ngDebugXXX()) that dumps trace to a console, a serial link or to a network. You will hopefully see a log of the execution that may help you to understand what is wrong. If this is impossible or irrelevant you can carry on through this check list...
  • Make sure you can rely on good material: check plugs, power supplies, serial cable, ethernet cable, hubs, etc.
  • Check the version number of each NexGen Software product (e.g. NexGenOS, NexGenIP, etc.). The first 3 digits must be the same for all products. See readme.txt file in each product for detailed dependencies.
  • Check your environment variables (NGOS, NGIP...) are pointing to the correct libraries
  • Rebuild the library if you have modify them, as well as any other source files used by the application.
  • Identify what part is not working. Has the NexGen Software even successfully pass the init phase? Is the TCP/IP stack up and running? Does it answer to pings and can it send pings? If not, you could check the next 2 questions.
  • Check that error codes returned by NexGen calls are always taken into account.
  • Check for stack overflow. Especially in RTOS mode, ensure to have enough stack space for each created task as the RTOS is likely not to check for stack overflows. This kind of trouble can be tricky as you might fall into it without actually knowing it. So always check that you do not place a tremendous amount of data in the stack, especially in callback functions which might be called by the libraries (e.g. from the TCP/IP stack) with several intermediate functions.
The TCP/IP stack does not reply to ping sent from another host. What could be wrong?

This could be hardware/physical issues (cable, hubs, etc.), driver issues or an ARP issue (if using ethernet).
Assuming you checked the first type, you could check for error count on the network interface with the ifconfig NexGenIP shell command.
If nothing is received (0 errors, 0 incoming bytes), a good thing to do is to use a sniffer (like tcpdump) to control what actually goes through the network.
If your network is silent, check you don't have a switch filtering packet on your network.
If packet on network are fine and good-looking, this is most likely an error in the configuration table (incorrect driver parameters).
At this step, a nice thing to do is to go back to a working test.
You could try to have a NexGen provided test working, and then have a close look at what parameters are provided into the configiuration table.

The TCP/IP stack failed to send ping request to an up-and-running host. What could be wrong?

You are most likely missing the RAWIP protocol in the configuration table.
This could also be a miss-configurated route table (the route table must tell how to reach the remote host).
The TCP/IP stack seems to work fine (I can ping it), but my application does not work. What could be wrong?

If you are trying to reach some network UNIX daemons through PPP, try to send a SIGHUP signal to the server once the PPP link has reach the UP state.
Some inetd servers do need this to answer incoming connection from a new PPP interface.
I got -39 errors (i.e. NG_ENOBUFS) at some point. What's wrong?

Typically everything works fine (packets are sent and received successfully) until a certain point is reached where NexGenIP returns -39 error codes.

Generally speaking, this occurs when applications are sending data too fast for the underlying physical layer. For instance, this may happen if an application is sending data too fast over a slow underlying serial link. So this is a typical application tuning issue.

There are at least 2 solutions. The first one is to increase the number of buffer available (see option NG_BUFO_MAX of NexGenIP configuration table). The second one is to somehow make the application sensitive to the underlying hardware speed. In other words, this can be done by changing the size of the send buffer on the socket.

    int s = 2048;               /* limits send queue to 2048 bytes */
    setsockopt( my_socket, NG_IOCTL_SOCKET, NG_SO_SNDBUF, &s, sizeof(s));

Off course, applications may also combine the 2 solutions.
The TCP/IP stack is out of socket descriptor: I got -31 errors (i.e. NG_EMFILE). What's wrong?

Your application reach a point where it requires more socket than available in the system at that moment.
Your NexGenIP configuration table is not correctly tuned regarding your application needs.

You can change (i.e. increase) the number of descriptors in your configuration table with options NG_SOCKO_MAX. The option NG_TCPO_TCB_MAX may also be changed to augment the number of TCP sockets.

Tuning the number of socket is made difficult by the well-known TCP TIME_WAIT state issue: once closed, TCP sockets are not freed immediatly and remains in this state for around 2 minutes.
This can cause the system to temporarilly run out of socket descriptors.
This normally occurs on server side.

Note: if you are using HTTP, try to enable persistent connections.