Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

nsip(4) [bsd man page]

NSIP(4) 						     Kernel Interfaces Manual							   NSIP(4)

NAME
nsip - software network interface encapsulating ns packets in ip packets. SYNOPSIS
#include <netns/ns_if.h> Not currently supported under 2.11BSD DESCRIPTION
The nsip interface is a software mechanism which may be used to transmit Xerox NS(tm) packets through otherwise uncooperative networks. It functions by prepending an IP header, and resubmitting the packet through the unix IP machinery. The super-user can advise the operating system of a willing partner by naming an IP address to be associated with an NS address. Presently, only specific hosts pairs are allowed, and for each host pair, an artificial point-to-point interface is constructed. At some future date, IP broadcast addresses or hosts may be paired with NS networks or hosts. Specifically, a socket option of SO_NSIP_ROUTE is set on a socket of family AF_NS, type SOCK_DGRAM, passing the following structure: struct nsip_req { struct sockaddr rq_ns; /* must be ns format destination */ struct sockaddr rq_ip; /* must be ip format gateway */ short rq_flags; }; DIAGNOSTICS
nsip%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), ns(4F) BUGS
It is absurd to have a separate pseudo-device for each pt-to-pt link. There is no way to change the IP address for an NS host once the the encapsulation interface is set up. The request should honor flags of RTF_GATEWAY to indicate remote networks, and the absence of RTF_UP should be a clue to remove that partner. This was intended to postpone the necessity of rewriting reverse ARP for the en device, and to allow passing XNS packets through an Arpanet-Milnet gateway, to facilitate testing between some co-operating universities. 3rd Berkeley Distribution January 27, 1996 NSIP(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 with the appropriate ioctl(2) commands for corresponding address families. 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 hardware 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
January 25, 2012 BSD
Man Page