The network drivers currently shipped with VxWorks are based on those available in BSD UNIX version 4.3. These drivers define only one global (user-callable) routine, the driver's attach routine. Typically, the name of this routine contains the word, attach, prefixed with two letters from the device name. For example, the AMD Lance driver's attach routine is called lnattach( ). The xxattach( ) routine hooks in five function pointers that are mapped into an ifnet structure. These functions, listed in Table 14-1, are all called from various places in the IP protocol stack, which has intimate knowledge of the driver.

Table 14-1:  Network Interface Procedure Handles

Packet reception begins when the driver's interrupt routine is invoked. The interrupt routine does the least work necessary to get the packet off the local hardware, schedules an input handler to run by calling netJobAdd( ), and then returns. The tNetTask calls the function that was added to its work queue. In the case of packet reception, this the driver's xxReceive( ) function.

The xxReceive( ) function eventually sends the packet up to a protocol by calling do_protocol_with_type( ). This routine is a switch statement that figures out which protocol to hand the packet off to. This calling sequence is shown in Figure 14-1.

Figure 14-2 shows the call graph for packet transmission. After a protocol has picked an interface on which to send a packet, it calls the xxOutput( ) routine for that interface. The output routine calls the generic ether_output( )function, passing it a pointer to addressing information (usually an arpcom structure) as well as the data to be sent. After the data is properly packed, it is placed on the output queue (using the IF_ENQUEUE macro), and the driver's start routine is called. The xxTxStartup( )routine dequeues as many packets as it can and transmits them on the physical medium.

You can use the etherInputHook( )and( )therOutputHook( )routines to bypass the TCP/IP stack and thus get access to raw packets. On packet reception, if an etherInputHook( ) function is installed, it receives the packet just after the driver has completed reception but before the packet goes to the protocol. If etherInputHook( ) decides to prevent others from seeing the packet, etherInputHook( ) returns a non-zero value and the driver considers the packet to be delivered. If the etherInputHook( ) returns 0, the driver hands the packet to the TCP/IP stack.

On packet transmission, an installed etherOutputHook( ) receives a packet just before it would have been transmitted. If etherOutputHook( ) decides to prevent the packet from passing on, etherOutputHook( ) returns a non-zero value and the driver considers the packet to be transmitted. If the etherOutputHook( ) returns 0, the driver transmits the packet.

It is only possible to install one etherInputHook( )and one etherOutputHook( )function per driver. This limits the number of alternate protocols to one, unless these ether*Hook routines then act as a multiplexor for more protocols.

For more information on etherhooks, see the Tornado BSP Developer's Kit for VxWorks, Tornado 1.0.1, User's Guide: G.4 Network Interface Hook Routines.