VxWorks / Tornado II FAQ

4. Network

4.1 Configuration problems

4.2 ARP

4.3 DHCP

4.4 FTP and TFTP

4.5 PPP

4.5.1 PPP on Windows 95

4.5.2 PPP on Windows NT

4.6 Sockets

4.7 Telnet

4.8 Other network related questions

Index

4. Network

4.1 Configuration problems

Q: How can I make my target vissible from other subnets?

A: Add the following line to usrNetInit():

if (params.gad[0] != EOS) routeAdd("0.0.0.0", params.gad);

Q: What is the correct sequence of function calls to install multiple END drivers and attach them to protocols

A: First make sure you have the extra interfaces in the table in confignet.h.
Then just look at the code in usrNetwork.c that brings up the boot device, and copy that to another function. Then you can call that function from usrRoot(), or the command line, or whenever...
Essentially:

       pEnd = endFindByName(dev, unit);
       muxIoctl(pEnd, EIOCGMIB2, (caddr_t) &endM2Tbl))
       ipAttach(unit, dev) != OK)
       bootNetmaskExtract (ipaddr, (int) &netmask);
       usrNetIfConfig (dev, unit, ipaddr, dbuf, netmask)
       printf("Attached TCP/IP interface to %s%d\n", dev, unit);

Q: How do I disable IP packet forwarding from one interface to another?

A: Edit target/h/netLib.h and change:

#define IP_FLAGS_DFLT           (IP_DO_FORWARDING | IP_DO_REDIRECT | \
                                 IP_DO_CHECKSUM_SND | IP_DO_CHECKSUM_RCV)

#define IP_FLAGS_DFLT           (/* IP_DO_FORWARDING | */ IP_DO_REDIRECT | \
                                 IP_DO_CHECKSUM_SND | IP_DO_CHECKSUM_RCV)

4.2 ARP

0x7F31990 (tNetTask): arp info overwritten for 8164de37 by 00.e0.16.66.96.52

A: This has happened because the network stack has updated its ARP entry for a given IP address after detecting that the ethernet address has changed. This normally should not happen in a well configured network....

'8164de37' is in fact the IP address whos ethernet address appears to have changed. eg. 129.100.222.55 in this case, and herein may well lie your problem.

At a guess, this is probably caused by having two hosts somewhere on the same network with the same IP address, one of which you would have in the ARP cache at boot-time - perhaps the boot server?
(From: molochai, molochai@vapour-trail.demon.co.uk)

4.3 DHCP

A: A sample lease storage routine which I used to test that hook can be found in this file. This code is not officially supported by WindRiver.
(From: Stephen Macmanus, stephenm@wrs.com)

Q: I have a problem in using the DHCP to get an IP address for the device that I am using.

A: There are some 'enhancements' to the VxWorks DHCP client that you will need if you want it to work under certain circumstances (e.g. at all in our case).
Because it's an enhancement rather than a bug fix (!) you can only get hold of it by asking your WRS contact directly - you won't find it on WindSurf.
But we had exactly this problem - dhcp client refusing to go - and it was fixed by these updated binaries.
(From: Luke Diamand, Diamand@btinternet.com)

Q: When I start a DHCP server on a port other ports stop working after some time.

A: The problem with the standard DHCP server is that it opens a socket for the DHCP channel (port number 67). This channel is used for sending data only. When a DHCP reply from another server is received it is put in the queue, but this queue is never read. The solution is to add a task to read the queue.
This problem and solution is known by WindRiver as SPR 31821. This is not (yet) available on WindSurf, but is available to the support engineers.

Q: After upgrading to Torndado 2.0.2 (aka T2CP4) the Solaris DHCP-server rejects the first 4 discover packets as being "short"
The first 4 packets the vxWorks dhcp client sends out are all 'short', (only 333 bytes long in my case), ending immediately after the outgoing client options.
Packets 5-8 are all 590 bytes long, where the first 333 bytes are identical to the first four packets and all the additional bytes in the packet are zeros - and these packets ARE accepted by the server, so I am successfully booting.
However, this results in an unacceptable and unnecessary delay in the overall dhcp boot process.

A: The difference in the patched DHCP and the previous DHCP versions lies in the differences in the RFC. RFC 2131 allows DHCP options field to have a size equal to the option fields. There is no required minimum on the options field length. The patched client follows RFC 2131.
DHCP servers complying with RFC 1541 do not acknowledge client messages conforming to the new RFC (the long wait).

According to Sun Support this issue is filed as a RFE (4310649) and is likely to get fixed in Solaris 9.
(From: Bruce Crozier, Bruce.Crozier@fci.com)

Q: How can I get a NT server to send the right parameters back after a DHCP request?

A: What you have to do is ask to NT server to send you DHCP configs tags wanted ..
user dhcpcOptionSet ( ) to Add theses options after dhcpcInit and before binding ...

dhcpcOptionSet( pVoidCookie, _DHCP_ROUTER_TAG, 3,  4, NULL ) ;

4.4 FTP and TFTP

A: The following was written by Curt McDowell (csm@broadcom.com) in the newsgroup:

I found a long-standing bug in VxWorks ftpLib that appears when transferring very small files from a relatively fast server to a relatively slow client.
Once ftpLib has initiated a transfer, it calls select() on both the control and data connections. It expects the data connection to become ready first. If the control connection becomes ready first, it assumes an error, closes both file descriptors and returns ERROR.
Unfortunately, it also assumes an error if the control and data connections become ready at the same time, which often happens in the conditions mentioned above.
The fix is to change one line in ftpLib.c (in my case 392) from

    if (FD_ISSET (ctrlSock, &readFds))

    if (FD_ISSET (ctrlSock, &readFds) && ! FD_ISSET (dataSock, &readFds))

    int c_fd;

    if (ftpXfer2(host, user, pass, "", "RNFR %s", dir, file_oldname,
                 &c_fd, NULL) == ERROR)
   ...

    if (ftpCommand(c_fd, "RNTO %s", (int) file_newname, 0,
                   0, 0, 0, 0) != FTP_COMPLETE)
   ...

    (void) ftpCommand(c_fd, "QUIT", 0, 0, 0, 0, 0, 0);
    close(c_fd);

Q: What is the meaning of all the ftp global variables?

A: These are the global variables of the FTP server:

• ftpdWindowSize: Socket level buffer size for send and receive sides (both). This can affect TCP window sizes. I was hoping that increasing this would help you.
• ftpdTaskPriority: main FTP daemon task priority
• ftpdWorkTaskOptions: task options of each of the spawned worker task that actually does file I/O, created by ftpdTask.
• ftpdDebug: Enable this to see some error logging messages
• ftpdWorkTaskStackSize: stack size of worker task
• ftpdWorkTaskPriority: priority of worker task

Q: How do I change the priority of the TFTP-task?

A: The tftp task is spawned at priority 55, and new incoming connection are spawned at priority 100, you can change this through the global variable tftpdResponsePriority which is initially set to 100.
(From: Stephen Hill, shill@dsl.ftel.co.uk)

Q: Is there source code available for an FTP server?

A: Yes, there is an FTP server included in DosFS2. This is in the unsupported sources tree.

4.5 PPP

4.5.1 PPP on Windows 95

FIRST VERSION. PLEASE SEND COMMENTS!

A: Windows 95 does not support a null-modem connection in Dial Up networking. To get this working a new device has to be defined. Kevin Wells has written a device driver to create a null modem connection. I modified this driver a bit to get it working with VxWorks. The original page is at http://www.kevin-wells.com/net/. Also the documentation for this driver can be found here.

Now for the installation under VxWorks.
First enable PPP in the configuration. Then download the driver VxWorksPPP.inf. Install this driver using Modems in the "Control Panel". Select "Add...", on the next screen check the "Don't detect my modem" box. Press "Next" and on that screen select "Have disk...". Now enter the path to where the file VxWorksPPP.inf was put. Now select the right communication port and "Next". Windows will now install this modem connection. Go to the properties of this modem. Set the right connection speed. Select the "Connection" tab, and then select the "Advanced" menu. Switch off Flow Control. To see if the link is working "Record a log file" can be checked. Now a logfile named "ModemLog.txt" will be generated in your Windows directory. Close all the windows. (This procedure is described in more detail on the site of Kevin Wells).
Now define a new Dial-up Networking connection using this device. The phone number is not important, as there is no phone line used but a null-modem cable. After this connection is defined go to the properties of this connection, go to the "Server Type" tab and uncheck everything except TCP/IP. Now go to "TCP/IP Settings". Uncheck everything here also. Also select "Server assigned IP address" and "Server assigned name server address". Close all windows using the "OK" button.
Now the PPP server has to be started on VxWorks. This can be done using usrPPPInit or pppInit. The first one uses the default parameters, with the second one a configuration can be specified. Here I will use pppInit.
First a configuration file has to be defined. The different items can be found in the VxWorks Network Programmers Guide, chapter 3.4 and Table 3-3. I use the following file (named PPP_OPT on the target):

debug
driver_debug
no_pap
no_chap
no_vj
lcp_max_configure 10
lcp_echo_interval 30
lcp_echo_failure 5

pppInit(0, "/tyCo/1", "90.0.0.1", "90.0.0.10", 38400, 0, "/D1/PPP_OPT")

How does this solution work? Windows 95 expects a reply from a modem before it will start the PPP communication. VxWorks starts the PPP communication directly. (This can be observed by starting the PPP server and watching the data on the serial line). To get Windows 95 to start the PPP driver the expected reply has been set to "~" (see the VxWorksPPP.inf file for this). This is the first character of the standard connect string. When VxWorks sends this string it is recognised by Windows 95 as a valid connect string, and the PPP driver is started. From then on the communication is running between VxWorks and Windows 95.
One problem with this solution is that VxWorks has to be sending the connect string. When VxWorks does not send this string no connection can be made. That is the reason why first the Dial-up Networking has to be started and then pppInit.
The "line lcp_max_configure 10" means that VxWorks will be sending 10 configuration requests before the PPP server dies. When the startup sequence is used as given in this example this is OK, but when a system has to monitor the PPP link continuously this value should be increased. I don't know if there is a value that means "contious". Otherwise a task should monitor if the PPP server still exists. If not a call to pppInit has to be made to restart the PPP server.
This solution has been found with the help of Stuart Gray and David Richards from WindRiver Systems.

4.5.2 PPP on Windows NT

A: There is a document from WindRiver, called WTN50.pdf. This is a Tech Note and available through WindSurf on the WindRiver website.

4.6 Sockets

Q: When I do a send using a socket connection to a second system, and this system crashes, the send still returns OK. How do I detect that the other side has failed?

A: The problem is that this is only detected using a timeout. The default parameters for KEEP ALIVE are set to detect a lost connection after some ridiculously long time like two hours. You can change this time by modifying the values of the variables tcp_keepintvl and tcp_keepidle. See the manual page for setsockopt under the SO_KEEPALIVE option.
(From: Charles H. Chapman, chc@nasa2.ksc.nasa.gov)

4.7 Telnet

A: Ask your local sales representative and he can provide you with source code to a telnet server that supports the target shell and your own custom thing. It was a component written by their Israel local office.
It's on the FAE FTP site, this is internal and password protected so normal folks can't get to it. If your FAE doesn't know where that is then tell them to go to internal.wrs.com and then follow the links to sales then FAE, after that they can't miss it.
It is free and quite small. It worked for us the same day we got it.
(From: Serge Blais, blais_serge@yahoo.com)

Q: How can I change the priority of the telnet task?

A: Just before the call to telnetInit in prjConfig.c add the line

telnetPriority=XXX

4.8 Other network related questions

Q: Does anyone point me in what is needed to support development of server/client TCP - BSD stream sockets applications using a NT platform with Microsoft Visual C/C++ (or Visual Studio) ?

A: The following is for MFC applications, see below for console (DOS like) apps:

1. In the App-Wizard (when creating the project), make sure you check the "include Winsock support" button.
2. Add the following to initialize the winsock dll (usually put in the OnInitXXX section) :

   //winsock stuff
   #ifdef WIN32
   #define WSOCK_VER 1   /* I have no idea what versions are what! 
                            version 1 seems to work with BSD 4.3 
                            type calls, ver 2 fails on a lot of 
                            machines  */
   WORD wVersionRequested;
   WSADATA wsaData;
   int err;
    
       wVersionRequested = MAKEWORD( WSOCK_VER, 0 );
    
       err = WSAStartup( wVersionRequested, &wsaData );
       if ( err != 0 ) 
       {
           return(1);
       }
    
       /* Confirm that the WinSock DLL supports This version */
       /* Note that if the DLL supports versions greater    */
       /* than WSOCK_VER in addition to WSOCK_VER, it will return */
       /* WSOCK_VER in wVersion since that is the version we      */
       /* requested.                                        */
    
       if ( LOBYTE( wsaData.wVersion ) != WSOCK_VER ||HIBYTE( wsaData.wVersion) != 0 ) 
       {
           return(2);
       }
   #endif
   

3. use all the regular BSD syntax calls. Look in help if you have problems (a few deviate slightly). Also, don't use iocti. Winsock needs ioctlsocket:

   #ifdef WIN32
       ioctlsocket (fd, FIONREAD, &numbytes);
   #else
       ioctl (fd, FIONREAD, &numbytes);
   #endif
   

Q: Has anyone succeed using an etherInputHook on an END style ethernet driver?

A: I've noticed on some T2 END ethernet drivers that the EtherHooks mechanism was disabled, i.e. the hook function simply never gets called. Two workarounds are possible for this: one is to use older BSD-style drivers (yes, this does work with the new SENS stack for backwards compatibility) and ether hooks, and the other is to implement a "SNARF" protocol which binds above the END's MUX and in general, provides the same functionality as the etherHooks.
The second solution is detailed in the SENS Network Protocol Toolkit. What they don't tell you is that there can be only one snarf protocol active at one time, and the default VxWorks image already installs such a protocol for what they call "system-mode debugging". Remove this and using the new method becomes almost as easy as the old etherHooks.
(From: Ran Shalgi, http://www.expand.com)

Q: Is there a TCP dump utility available for VxWorks?

A: Take a look at this program. It has been flkoating around for some time, I don't know the author: vxsniff.c

Q: At boottime I get a "dc0 - no carrier" error. What does this mean?

A: I had to download the latest driver from WindRiver and make a change to my sysDec21x40End.c file. Look for the latest driver releases from WindSurf (click on download, tornado 2.0 drivers). That will update your driver binary.

After installing the new driver binary, add the following to the sysDec*.c file in the MV2700 directory:

    sprintf (cp, decParamTemplate,
                 (UINT) (iobaseCsr),     /* device io base */
                 (UINT) PCI_SLV_MEM_BUS, /* pciMemBase */
                  irqvec,                /* interrupt irq vector */
                  irqnum,                /* interrupt irq number */
                /*NET_END_USER_FLAGS);*/
                  NET_END_USER_FLAGS | DEC_USR_MII,
                  8,                     /* phyAddr*/
                  0,                     /*pPhyTbl*/
                                         /*phyFlags*/
                  DEC_USR_MII_10MB | DEC_USR_MII_100MB |
                  DEC_USR_MII_HD | DEC_USR_MII_FD );

Q: Is there any vxworks routine to get the default gateway address on a vxworks target?

A: I haven't seen an API routine, but... The data is globally available in the kernels we use via the bootline parameters:

BOOT_PARAMS params;
extern char *sysBootLine;
if (usrBootLineCrack (sysBootLine, &params) == OK)
{
    if (params.gad[0] != EOS)
    {
        /* it is specified... */
        routeAdd ("0.0.0.0", params.gad);
    }
}

Q: How do I get the MAC address using the VxWorks API?

A: Here's how I do it:

        UINT8 macBuffer[8];
        sysCpmEnetAddrGet(0, macBuffer);
        MacAddr = nlprintf("0x%02X%02X%02X%02X%02X%02X",
                                                macBuffer[0],
                                                macBuffer[1],
                                                macBuffer[2],
                                                macBuffer[3],
                                                macBuffer[4],
                                                macBuffer[5]);

Q: Is well-known port 7 implemented, and if not, how can I implement this?

A: As far as I know this is not implemented in release 5.4. Our implementation did a readfrom/sendto as this gives you the source address
Here is the 'work part' of our echo daemon:

struct sockaddr sa;
char buffer[BUFFSIZE];
int i,size;

if((i=recvfrom(s,buffer,sizeof(buffer),0,&sa,&size))) < 0)
        return;
(void) sendto(s,buffer,i,0,&sa,sizeof(sa));
        return;

Q: When calling netPoolDelete,does the memory get freed?

A: The pNetPool memory will not be freed. It will be bzero'd before netPoolDelete returns. The pPoolStat, if non-null will be freed and the CL_POOL clTbl[CL_TBL_SIZE] will be checked and nulled after freeing entries that have been malloc'd.
((From: DrDiags, drdiags@flashcom.net)

Q: How do I change the MAC-address of an interface?

A: This answer consists of 2 parts, the first part describes how to change the MAC-address itself, the second part describes how to propagate this change onto the network.

    IP_DRV_CTRL *ip_info;
    int unit;
    extern int ipMaxUnits;

    for (unit = 0; unit < ipMaxUnits; unit++) {
        ip_info = ipDrvCtrl + unit;
        if (strcmp( if_name, ip_info->idr.ac_if.if_name ))
            continue;
        if (if_unit != ip_info->idr.ac_if.if_unit)
            continue;

        bcopy( new_address, ip_info->idr.ac_enaddr, 6 );
        break;
    }

• Bring the interface down then up. The TCP/IP stack should broadcast an unsolicited ARP when it brings up an interface with an IP address.
• call ifAddrSet() on the interface. The stack broadcasts an unsolicited ARP when an IP address is assigned to an interface.
• open a raw socket, create and populate your own unsolicited ARP packet, then broadcast it.

Q: I cannot mount my ATA CDROM drive

A: This is because CD-ROM drives usually do not implement the ATA protocol, as hard drives do, but instead use the ATAPI protocol, which runs over the same IDE hardware but is something else.
Couple of years back we did an ATAPI driver addition, which makes the VxWorks ATA driver know both ATA and ATAPI protocols, but its burried somewhere at WindRiver. Try to ask your FAE to get you the driver.
(From: Leonid Rosenboim, leonid@bitband.com)

Index