Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

ec(4) [bsd man page]

EC(4)							     Kernel Interfaces Manual							     EC(4)

NAME
ec - 3Com 10 Mb/s Ethernet interface SYNOPSIS
/sys/conf/SYSTEM: NEC ec_controllers # 3Com Ethernet DESCRIPTION
The ec interface provides access to a 10 Mb/s Ethernet network through a 3com controller. The hardware has 32 kilobytes of dual-ported memory on the UNIBUS. This memory is used for internal buffering by the board, and the inter- face code reads the buffer contents directly through the UNIBUS. The address of this memory is given in the flags field in the configura- tion file. The first interface normally has its memory at Unibus address 0. Each of the host's network addresses is specified at boot time with an SIOCSIFADDR ioctl. The ec interface employs the address resolution protocol described in arp(4P) to dynamically map between Internet and Ethernet addresses on the local network. The interface normally tries to use a ``trailer'' encapsulation to minimize copying data on input and output. The use of trailers is nego- tiated with ARP. This negotiation may be disabled, on a per-interface basis, by setting the IFF_NOTRAILERS flag with an SIOCSIFFLAGS ioctl. The interface software implements an exponential backoff algorithm when notified of a collision on the cable. This algorithm utilizes a 16-bit mask and the VAX-11's interval timer in calculating a series of random backoff values. The algorithm is as follows: 1. Initialize the mask to be all 1's. 2. If the mask is zero, 16 retries have been made and we give up. 3. Shift the mask left one bit and formulate a backoff by masking the interval timer with the smaller of the complement of this mask and a 5-bit mask, resulting in a pseudo-random number between 0 and 31. This produces the number of slot times to delay, where a slot is 51 microseconds. 4. Use the value calculated in step 3 to delay before retransmitting the packet. The delay is done in a software busy loop. DIAGNOSTICS
ec%d: send error. After 16 retransmissions using the exponential backoff algorithm described above, the packet was dropped. ec%d: input error (offset=%d). The hardware indicated an error in reading a packet off the cable or an illegally sized packet. The buffer offset value is printed for debugging purposes. ec%d: can't handle af%d. The interface was handed a message with addresses formatted in an unsuitable address family; the packet was dropped. SEE ALSO
intro(4N), inet(4F), arp(4P) BUGS
The hardware is not capable of talking to itself. The software implements local sending and broadcast by sending such packets to the loop interface. This is a kludge. Backoff delays are done in a software busy loop. This can degrade the system if the network experiences frequent collisions. 3rd Berkeley Distribution August 20, 1987 EC(4)

Check Out this Related Man Page

LO(4)                                                      BSD Kernel Interfaces Manual                                                      LO(4)

NAME
lo -- software loopback network interface SYNOPSIS
device loop DESCRIPTION
The loop interface is a software loopback mechanism which may be used for performance analysis, software testing, and/or local communication. As with other network interfaces, the loopback interface must have network addresses assigned for each address family with which it is to be used. These addresses may be set or changed with the SIOCSIFADDR ioctl(2). The loopback interface should be the last interface configured, as protocols may use the order of configuration as an indication of priority. The loopback should never be configured first unless no hard- ware interfaces exist. If the transmit checksum offload capability flag is enabled on a loopback interface, checksums will not be generated by IP, UDP, or TCP for packets sent on the interface. If the receive checksum offload capability flag is enabled on a loopback interface, checksums will not be validated by IP, UDP, or TCP for packets received on the interface. By default, both receive and transmit checksum flags will be enabled, in order to avoid the overhead of checksumming for local communication where data corruption is unlikely. If transmit checksum generation is disabled, then validation should also be disabled in order to avoid packets being dropped due to invalid checksums. DIAGNOSTICS
lo%d: can't handle af%d. The interface was handed a message with addresses formatted in an unsuitable address family; the packet was dropped. SEE ALSO
inet(4), intro(4) HISTORY
The lo device appeared in 4.2BSD. The current checksum generation and validation avoidance policy appeared in FreeBSD 8.0. BSD March 15, 2009 BSD
Man Page