If the configuration option CYGBLD_NET_LWIP_BUILD_MANUAL_TESTS is enabled then a set of simple tests are built. Note: The option is disabled by default. These are just basic verification tests and are not designed to be an exhaustive test of all lwIP or TCP/IP networking features.

For the tests frag and udpecho the host tool nc (netcat) can be used to interface with the test. In the following sections any examples given of using the tests assume that the Unit Under Test (UUT) is at the local network IPv4 address The actual local addresses for the UUT should be ascertained and substituted accordingly.

Note: Most of the tests are currently limited to accepting IPv4 connections. The exceptions are socket and tcpecho which will accept IPv4 or IPv6 connections.


This is a very simple TCP protocol test using the BSD-alike socket API. The test will listen for two IPv4 or IPV6 connections on port 7. For each connection established the test will continue to echo the data received on the TCP stream until the particular connection is closed.

The nc utility can be used to communicate with the test program.

nc 7

After starting nc the UUT will acknowledge the connection by displaying:

PASS:<Received connection OK>
it which point it will wait for a line of text to be input and completed by pressing the Enter key. Multiple lines of text can be entered, and should be echoed back to indicate that the UUT has received and responded OK. Entering Ctrl-D will terminate the nc connection.

Another execution of nc as above will complete the test.


This is a very simple TCP protocol test. See the Section called socket for a description of the test, since it has identical requirements to that example.


This is a very simple UDP protocol test, listening for two connections on port 7 and echo-ing back the data received.

The nc utility can be used to communicate with the test program.

nc -u 7

After starting nc it will wait for a line of text to be input and completed by pressing the Enter key. The nc will then perform the necessary UDP connection to the specified port, transmit the data and output any reply. Another line of text can then be entered to complete the test. Unlike the tcpecho a single nc execution can be used for the test, since each line transmitted counts as a single UDP connection test.


This is a simple test that should result in fragmented TCP packets being transmitted. The test can be exercised like the Section called udpecho since it listens for two UDP connections on port 7.

The major difference being that after echoing the received data the UUT will transmit a large amount of data to the host nc.


This test provides a client for use with the host side CYGPKG_NET nc_test_master application. The host side test code must be manually built within the packages/net/common/vsn/tests directory.

When the UUT is started it will initially perform some slave performance calculations before it will start listening for connections.


This is a very simple HTTP daemon that will listen for two HTTP GET connections on port 80. Currently only IPv4 socket connections are listened for. The test when started will display some information on the diagnostic channel, including:

PASS:<Listening on TCP port 80>
INFO:<Will wait for two HTTP connections>

When it is has displayed the “Will wait ...” message the UUT is ready to be accessed from the test host. The following example uses the host tool wget to perform such a page fetch, and can be executed twice to perform the test. e.g.


After the second GET operation the test will exit.


This is a slightly more realistic HTTP daemon test, that will execute indefinitely. This test is a useful example of using the raw API, and could form the basis of a simple, lightweight, webserver.

Currently it will only accept IPv4 socket connections on port 80. On startup it will not display any diagnostic output other than the cyg_lwip_netif_print_info( netif_default, diag_printf ) output displaying the default network interface address information.

A standard web browser can be used to access the pages served by the daemon, returning a simple demonstration page as the root document. The test has been designed to be extendible to easily support multiple pages.


If IPv4 DNS support is configured then this test performs some simple verification using some known lookups against the locally configured DNS address (e.g. obtained via DHCP), and then again using a known fixed DNS server.


This is a simple stand-alone test of the lwIP internal timeout handling. No external interaction is required.

Documentation license for this page: eCosPro License