📄 vxw_pt4.html
字号:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="VIM on Unix and Win95"> <meta name="Author" content="Johan Borkhuis"> <meta name="description" content="VxWorks / Tornado II information / FAQ"> <meta name="keywords" content="VxWorks,Tornado,FAQ"> <meta name="version" content="$Id: vxw_pt4.html,v 1.19 2002/04/25 08:26:13 borkhuis Exp $"> <title>VxWorks and Tornado II FAQ</title></head><body><center><h1><strong><font size="+4">VxWorks / Tornado II FAQ</font></strong></h1></center><p><hr WIDTH="80%"><h2><a href="#4">4. Network</a></h2><blockquote><h3><a href="#4.1">4.1 Configuration problems</a></h3></blockquote><blockquote><h3><a href="#4.2">4.2 ARP</a></h3></blockquote><blockquote><h3><a href="#4.3">4.3 DHCP</a></h3></blockquote><blockquote><h3><a href="#4.4">4.4 FTP and TFTP</a></h3></blockquote><blockquote><h3><a href="#4.5">4.5 PPP</a></h3><blockquote><h4><a href="#4.5.1">4.5.1 PPP on Windows 95</a></h4></blockquote><blockquote><h4><a href="#4.5.2">4.5.2 PPP on Windows NT</a></h4></blockquote><blockquote><h4><a href="#4.5.3">4.5.3 PPP on Solaris</a></h4></blockquote></blockquote><blockquote><h3><a href="#4.6">4.6 Sockets</a></h3></blockquote><blockquote><h3><a href="#4.7">4.7 Telnet</a></h3></blockquote><blockquote><h3><a href="#4.8">4.8 Other network related questions</a></h3></blockquote><blockquote><h3><a href="#index">Index</a></h3></blockquote><hr WIDTH="80%"><p><h2><a NAME="4"><center>4. Network</center></a></h2><p><h3><a NAME="4.1"><center>4.1 Configuration problems</center></a></h3><a NAME="4.1-A"></a><p>Q: How can I make my target vissible from other subnets?<p>A: Add the following line to usrNetInit():<pre>if (params.gad[0] != EOS) routeAdd("0.0.0.0", params.gad);</pre>The nice thing about doing it this way is your default route will alwaysbe to the gateway you enter at the boot prompt, so if you ever change thatthe default route will automatically follow.<br>(From: David E. Chavez)<p><hr WIDTH="50%"><a NAME="4.1-B"></a><p>Q: What is the correct sequence of function calls to install multiple ENDdrivers and attach them to protocols<p>A: First make sure you have the extra interfaces in the table inconfignet.h.<br>Then just look at the code in usrNetwork.c that brings up the bootdevice, and copy that to another function. Then you can call thatfunction from usrRoot(), or the command line, or whenever...<br>Essentially:<pre> 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);</pre>Be aware that you can not re-use the "unit number", even if you havedifferent devices. VxWorks does not support the notion ofa "minor" number when assigning network interfaces, only "major"numbers. These are the numbers in the END table in confignet.h, and mustall be distinct. This does not mean you need multiple copies of thedriver code - you still check the unit number in the driver and allthat. I.e. on an 8260 with networks on the SCCs and FCCs, you can'thave scc0 and fcc0, the unit number for any network interface must beunique.<br>(From: Dan, gold@sdsu.edu, and Brian St. Pierre)<p><hr WIDTH="50%"><a NAME="4.1-C"></a><p>Q: How do I disable IP packet forwarding from one interface to another?<p>A: Edit target/h/netLib.h and change:<pre>#define IP_FLAGS_DFLT (IP_DO_FORWARDING | IP_DO_REDIRECT | \ IP_DO_CHECKSUM_SND | IP_DO_CHECKSUM_RCV)</pre>to:<pre>#define IP_FLAGS_DFLT (/* IP_DO_FORWARDING | */ IP_DO_REDIRECT | \ IP_DO_CHECKSUM_SND | IP_DO_CHECKSUM_RCV)</pre>(or do something else that has the same effect).<br>(From David Laight, dsl@tadpole.co.uk)<p><hr WIDTH="50%"><a NAME="4.1-D"></a><p>Q: How can I tune the performance of the network stack?<p>A: More information about this can be found in the following documents:<ul><li><A HREF="netPerformance.txt">Sens/Tornado 2.0 Network Stack Configuration/Performance Issues</a></li><li><A HREF="troubleshooting.txt">Troubleshooting Simple Network Problems InTornado 2.0</a></li></ul>together with this source file: <A HREF="utilities.c">utilities.c</a>.<br>(From: DrDiags, drdiags@covad.net)<p><hr WIDTH="60%"><p><h3><a NAME="4.2"><center>4.2 ARP</center></a></h3><a NAME="4.2-A"></a>Q: On bootup of my system I am getting the following message:<pre>0x7F31990 (tNetTask): arp info overwritten for 8164de37 by 00.e0.16.66.96.52</pre>What does this message mean?<p>A: This has happened because the network stack has updated its ARP entry fora given IP address after detecting that the ethernet address has changed. Thisnormally should not happen in a well configured network....<p>'8164de37' is in fact the IP address whos ethernet address appears to havechanged. eg. 129.100.222.55 in this case, and herein may well lie yourproblem. <p>At a guess, this is probably caused by having two hosts somewhere on the samenetwork with the same IP address, one of which you would have in the ARPcache at boot-time - perhaps the boot server?<br>(From: molochai, molochai@vapour-trail.demon.co.uk)<p><hr WIDTH="60%"><p><h3><a NAME="4.3"><center>4.3 DHCP</center></a></h3><a NAME="4.3-A"></a>Q: I am trying to implement a DHCP server using vxWorks.To do it we have to implement a lease storage routine and addressstorage routine. I was wondering if there is any sample code that showshow to implement those routines.<p>A: A sample lease storage routine which I used to test that hook can befound <a href="dhcpSampleHook.c">in this file</a>.This code is not officially supported by WindRiver.<br>(From: Stephen Macmanus, stephenm@wrs.com)<p><hr WIDTH="50%"><a NAME="4.3-B"></a><p>Q: I have a problem in using the DHCP to get an IP address for the devicethat I am using.<p>A: There are some 'enhancements' to the VxWorks DHCP client that youwill need if you want it to work under certain circumstances (e.g.at all in our case). <br>Because it's an enhancement rather than a bug fix (!) you can onlyget hold of it by asking your WRS contact directly - you won't findit on WindSurf.<br>But we had exactly this problem - dhcp client refusing to go - andit was fixed by these updated binaries.<br>(From: Luke Diamand, Diamand@btinternet.com)<p><hr WIDTH="50%"><a NAME="4.3-C"></a><p>Q: When I start a DHCP server on a port other ports stop working after sometime.<p>A: The problem with the standard DHCP server is that it opens a socket forthe DHCP channel (port number 67). This channel is used for sending dataonly. When a DHCP reply from another server is received it is put in thequeue, but this queue is never read. The solution is to add a task to readthe queue.<br> This problem and solution is known by WindRiver as SPR 31821. This isnot (yet) available on WindSurf, but is available to the support engineers.<p><hr WIDTH="50%"><a NAME="4.3-D"></a><p>Q: After upgrading to Torndado 2.0.2 (aka T2CP4) the Solaris DHCP-serverrejects the first 4 discover packets as being "short"<br>The first 4 packets the vxWorks dhcp client sends out are all 'short',(only 333 bytes long in my case), ending immediately after the outgoingclient options.<br>Packets 5-8 are all 590 bytes long, where the first 333 bytes are identicalto the first four packets and all the additional bytes in the packet arezeros - and these packets ARE accepted by the server, so I am successfullybooting.<br>However, this results in an unacceptable and unnecessary delay in the overalldhcp boot process.<p>A: The difference in the patched DHCP and the previous DHCP versions lies inthe differences in the RFC. RFC 2131 allows DHCP options field to have a size equalto the option fields. There is no required minimum on the options field length.The patched client follows RFC 2131.<br>DHCP servers complying with RFC 1541 do not acknowledge client messagesconforming to the new RFC (the long wait).<p> According to Sun Support this issue is filed as a RFE (4310649) and is likelyto get fixed in Solaris 9.<br>(From: Bruce Crozier, Bruce.Crozier@fci.com)<p><hr WIDTH="50%"><a NAME="4.3-E"></a><p>Q: How can I get a NT server to send the right parameters back after a DHCPrequest?<p>A: What you have to do is ask to NT server to send youDHCP configs tags wanted ..<br>user dhcpcOptionSet ( ) to Add theses options after dhcpcInit and beforebinding ...<pre>dhcpcOptionSet( pVoidCookie, _DHCP_ROUTER_TAG, 3, 4, NULL ) ;</pre>See the RFC for more details on each tag and numbers<br>(From: "Steeve Gagne, steeve.gagne@simplernetworks.com)<p><hr WIDTH="50%"><a NAME="4.3-F"></a><p>Q: When I enable the DHCP client I cannot connect anymore using WDB.<p>A: I think I know what happens. Basically, this is a well known problemwith SNARF protocol.<br>Here is a basic explaination:<ol><li>An end network interface can have at most 1 protocol registered asSNARF (Type 257), which protocol that sees all packets.</li><li>The default build in Tornado 2.0 is to have the WDB agent use theEnd driver connection mode which registers the WDB agent as a SNARFprotocol. In this mode, the WDB agent will be able to do system modedebugging over Ethernet.</li><li>DHCP client, server and relay and etherInputHookAdd also registeras SNARF protocol. However, the implementation of DHCP client, server,and relay preceded end drivers. The initialization of DHCP happensfirst. The WDB agent is configured after the network is initialized.If DHCP is used, the WDB agent communication setup will fail, and thetarget server will report RPC core backend timeout.</li></ol>Solution: <br>To change how the WDB agent communicates to Tornado, selectingNetwork connection instead of END connection. In config.h, change"#define WDB_COMM_TYPE WDB_COMM_END" to "#define WDB_COMM_TYPEWDB_COMM_NETWORK"<p>Tradeoff:<br>After this change, the WDB agent will NOT be able to do system modedebugging over Ethernet. Only task mode debugging may be performed. Ifsomeone prefer system mode debugging sometimes, the DHCP Server must beremoved and the WDB agent must be switched back to END connection.<br>(From: Charlie Zhao, czhao@hns.com)<p><hr WIDTH="60%"><p><h3><a NAME="4.4"><center>4.4 FTP and TFTP</center></a></h3><a NAME="4.4-A"></a>Q: When I send files to my target using FTP small files fail often, butlarger don't have any problem at all.<p>A: The following was written by Curt McDowell (csm@broadcom.com) in thenewsgroup:<p>I found a long-standing bug in VxWorks ftpLib that appears whentransferring very small files from a relatively fast server to arelatively slow client.<br>Once ftpLib has initiated a transfer, it calls select() on both thecontrol and data connections. It expects the data connection to becomeready first. If the control connection becomes ready first, it assumesan error, closes both file descriptors and returns ERROR.<br>Unfortunately, it also assumes an error if the control and dataconnections become ready at the same time, which often happens in theconditions mentioned above.<br>The fix is to change one line in ftpLib.c (in my case 392) from<pre> if (FD_ISSET (ctrlSock, &readFds))</pre>to<pre> if (FD_ISSET (ctrlSock, &readFds) && ! FD_ISSET (dataSock, &readFds))</pre>Apparently there was an SPR opened for this problem about 18 months agoby Paul Banta. Unfortunately nothing ever came of this. Thanks go toPaul Banta, who also experienced the problem and reported in.<br>In the mean time, I have a version of the routine I call ftpXfer2()which has the same parameters as ftpXfer(). It does not contain any WRScode. <br>In addition to fixing the small-file flaky transfer problem, it alsofixes a bug prohibiting FTP_CONTINUE responses, which allows filerenaming to work as follows (error checking omitted):<pre> 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);</pre>And now for the code: <a href="ftpXfer2.c">ftpXfer2.c</a>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -