Unix (all-caps UNIX for the trademark) is a family of multitasking, multiuser computer operating systems that derive from the original AT&T Unix, developed in the 1970s at the Bell Labs research center by Ken Thompson, Dennis Ritchie, and others.

Rbcafe » Unix



SHA1, SHA1_Init, SHA1_Update, SHA1_Final – Secure Hash Algorithm


#include (openssl/sha.h)

unsigned char *SHA1(const unsigned char *d, unsigned long n,
unsigned char *md);

void SHA1_Init(SHA_CTX *c);
void SHA1_Update(SHA_CTX *c, const void *data,
unsigned long len);
void SHA1_Final(unsigned char *md, SHA_CTX *c);


SHA-1 (Secure Hash Algorithm) is a cryptographic hash function with a
160 bit output.

SHA1() computes the SHA-1 message digest of the n bytes at d and places
it in md (which must have space for SHA_DIGEST_LENGTH == 20 bytes of
output). If md is NULL, the digest is placed in a static array.

The following functions may be used if the message is not completely
stored in memory:

SHA1_Init() initializes a SHA_CTX structure.

SHA1_Update() can be called repeatedly with chunks of the message to be
hashed (len bytes at data).

SHA1_Final() places the message digest in md, which must have space for
SHA_DIGEST_LENGTH == 20 bytes of output, and erases the SHA_CTX.

Applications should use the higher level functions EVP_DigestInit(3)
etc. instead of calling the hash functions directly.

The predecessor of SHA-1, SHA, is also implemented, but it should be
used only when backward compatibility is required.


SHA1() returns a pointer to the hash value.
SHA1_Init(), SHA1_Update() and SHA1_Final() do not return values.


SHA: US Federal Information Processing Standard FIPS PUB 180 (Secure
Hash Standard), SHA-1: US Federal Information Processing Standard FIPS
PUB 180-1 (Secure Hash Standard), ANSI X9.30


Rbcafe » Unix



closelog, openlog, syslog – send messages to the system



void openlog( char *ident, int option, int facility)

void syslog( int priority, char *format, …)

void closelog( void )


closelog() closes the descriptor being used to write to
the system logger. The use of closelog() is optional.

openlog() opens a connection to the system logger for a
program. The string pointed to by ident is added to each
message, and is typically set to the program name. Values
for option and facility are given in the next section.
The use of openlog() is optional; It will automatically be
called by syslog() if necessary, in which case ident will
default to NULL.

syslog() generates a log message, which will be dis-
tributed by syslogd(8). priority is a combination of the
facility and the level, values for which are given in the
next section. The remaining arguments are a format, as in
printf(3) and any arguments required by the format, except
that the two character %m will be replaced by the error
message string (strerror) corresponding to the present
value of errno.


This section lists the parameters used to set the values
of option, facility, and priority.

The option argument to openlog() is an OR of any of these:

write directly to system console if there is an
error while sending to system logger

open the connection immediately (normally, the con-
nection is opened when the first message is logged)

print to stderr as well

include PID with each message

The facility argument is used to specify what type of pro-
gram is logging the message. This lets the configuration
file specify that messages from different facilities will
be handled differently.

security/authorization messages (DEPRECATED Use

security/authorization messages (private)

clock daemon (cron and at)

other system daemons

kernel messages

reserved for local use

line printer subsystem

mail subsystem

USENET news subsystem

messages generated internally by syslogd

generic user-level messages

UUCP subsystem

This determines the importance of the message. The levels
are, in order of decreasing importance:

system is unusable

action must be taken immediately

critical conditions

error conditions

warning conditions

normal, but significant, condition

informational message

debug-level message


A syslog function call appeared in BSD 4.2.


logger(1), syslog(5), syslogd(8)


Updated: Donnerstag, 18UTCThu, 18 Aug 2016 13:06:48 +0000 18. August 2016 — 1:06

Rbcafe » Unix

Tcp Dump

Tcp Dump

This command line tool is included with all versions of Mac OS X, and is also available on many other Unix platforms. To get started, try the following command.

sudo tcpdump -i en0 -s 0 -w DumpFile.dmp

Each element of the command line is explained below.

The sudo command causes tcpdump to run with privileges, which is necessary to access promiscuous mode.

The -i en0 option tells tcpdump to capture packets on the first Ethernet interface. You need to select an interface; there is no default. For a list of interfaces, type ifconfig -a. Mac OS X 10.1 and later provide packet capture support on PPP, so you can also specify a PPP interface here (for example, -i ppp0).

Note: If you need to capture PPP packets on traditional Mac OS, try using Interarchy or Sample Code Project ‚OTStreamDumper‘.

The -s 0 option requests the full packet rather than just the first 68 bytes.
The -w DumpFile.dmp parameter tells tcpdump to dump the packets to a file called DumpFile.dmp.

In response to this command, tcpdump will begin to capture packets and put them in the DumpFile.dmp file. When you want to stop capturing, interrupt tcpdump by typing ^C. You can then display the contents of the packets as text using the following command.

tcpdump -s 0 -n -e -x -vvv -r DumpFile.dmp

New elements of the command line are explained below.

The -n option means that addresses are not converted to domain names, which speeds things up considerably.
The -e option causes tcpdump to display the link-level header for each packet.
The -x option causes the contents of the packet to also be displayed in hex.
The -vvv option makes tcpdump’s output as verbose as possible.

By specifying -r DumpFile.dmp option you tell tcpdump to read packets from the file DumpFile.dmp rather than from a network interface. Note that you don’t need privileges to do this, so running tcpdump using sudo is not required.

You can also combine these steps, as shown below, but if you do this you don’t get a high-fidelity record of the packets that you captured.

sudo tcpdump -i en0 -s 0 -n -e -x -vvv

You can learn about tcpdump from the online manual and from the book TCP/IP Illustrated, Volume 1, The Protocols, W Richard Stevens, Addison-Wesley, 1994, ISBN 0-201-63346-9. That book is also an excellent introduction to TCP/IP protocols in general.

Note: Mention of third party sites and third party products is for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the selection, performance, or use of these vendors or products.

Miscellaneous Notes

Some of these tools have problems with packets being transferred to or from the trace machine (the machine running the tool). In general I recommend that your trace machine be separate from the machines whose network traffic you’re tracing. If you don’t follow this advice, please note the following anomalies.

EtherPeek on traditional Mac OS is unable to see packets being sent by the trace machine.

On Mac OS X, both EtherPeek and tcpdump will display bad IP checksums for packets being sent by the trace machine.

You should consult the documentation that comes with your tool for accurate and up-to-date information about its limitations.

If you use a separate trace machine, make sure that you connect all of the machines via a passive hub rather than a switch. Virtually all 10/100 hubs are actually switches, so you’ll probably have to dig through your boxes of old stuff for a 10 Mbit/s-only passive hub (or specifically look for a 10/100 hub that only switches between the different speed segments, for example the SMC-EZ58xxDS range).

If you send a packet trace to DTS, please include the following:

The name and version of the tool you used to capture the packet trace.

The system type and OS version of the trace machine.

If you’ve used either EtherPeek or tcpdump to capture your packet trace, you can send us the packet trace file in its native format. Otherwise, please include a copy of the packet trace in both its native format and, if that native format isn’t text, a text export of the trace as well. That way we’re guaranteed to be able to read your packet trace.

For each relevant machine shown in the trace, please describe the following:

The machine’s role in the network conversation.

The system type and OS version.

The machine’s IP address.

The machine’s hardware address (also known as the Ethernet address or MAC address).


Rbcafe » Unix


traceroute – print the route packets take to network host


traceroute [ -Sdnrv ] [ -g gw_host ] [ -m max_ttl ]
[ -p port ] [ -q nqueries ] [ -s src_addr ]
[ -t tos ] [ -w waittime ] host [ packetlen ]


The Internet is a large and complex aggregation of network
hardware, connected together by gateways. Tracking the
route one’s packets follow (or finding the miscreant gate-
way that’s discarding your packets) can be difficult.
Traceroute utilizes the IP protocol `time to live‘ field
and attempts to elicit an ICMP TIME_EXCEEDED response from
each gateway along the path to some host.

The only mandatory parameter is the destination host name
or IP number. The default probe datagram length is 40
bytes, but this may be increased by specifying a packet
length (in bytes) after the destination host name.

Other options are:

-S Print a summary of how many probes were not
answered for each hop.

-g Specify a loose source route gateway (8 maximum).

-m Set the max time-to-live (max number of hops) used
in outgoing probe packets. The default is 30 hops
(the same default used for TCP connections).

-n Print hop addresses numerically rather than symbol-
ically and numerically (saves a nameserver address-
to-name lookup for each gateway found on the path).

-p Set the base UDP port number used in probes
(default is 33434). Traceroute hopes that nothing
is listening on UDP ports base to base + nhops – 1
at the destination host (so an ICMP PORT_UNREACH-
ABLE message will be returned to terminate the
route tracing). If something is listening on a
port in the default range, this option can be used
to pick an unused port range.

-r Bypass the normal routing tables and send directly
to a host on an attached network. If the host is
not on a directly-attached network, an error is
returned. This option can be used to ping a local
host through an interface that has no route through
it (e.g., after the interface was dropped by

-s Use the following IP address (which must be given
as an IP number, not a hostname) as the source
address in outgoing probe packets. On hosts with
more than one IP address, this option can be used
to force the source address to be something other
than the IP address of the interface the probe
packet is sent on. If the IP address is not one of
this machine’s interface addresses, an error is
returned and nothing is sent.

-t Set the type-of-service in probe packets to the
following value (default zero). The value must be
a decimal integer in the range 0 to 255. This
option can be used to see if different types-of-
service result in different paths. (If you are not
running 4.4bsd, this may be academic since the nor-
mal network services like telnet and ftp don’t let
you control the TOS). Not all values of TOS are
legal or meaningful – see the IP spec for defini-
tions. Useful values are probably `-t 16′ (low
delay) and `-t 8′ (high throughput).

-v Verbose output. Received ICMP packets other than

-w Set the time (in seconds) to wait for a response to
a probe (default 5 sec.).

This program attempts to trace the route an IP packet
would follow to some internet host by launching UDP probe
packets with a small ttl (time to live) then listening for
an ICMP „time exceeded“ reply from a gateway. We start
our probes with a ttl of one and increase by one until we
get an ICMP „port unreachable“ (which means we got to
„host“) or hit a max (which defaults to 30 hops & can be
changed with the -m flag). Three probes (change with -q
flag) are sent at each ttl setting and a line is printed
showing the ttl, address of the gateway and round trip
time of each probe. If the probe answers come from dif-
ferent gateways, the address of each responding system
will be printed. If there is no response within a 5 sec.
timeout interval (changed with the -w flag), a „*“ is
printed for that probe.

We don’t want the destination host to process the UDP
probe packets so the destination port is set to an
unlikely value (if some clod on the destination is using
that value, it can be changed with the -p flag).

A sample use and output might be:

[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (, 30 hops max, 38 byte packet
1 helios.ee.lbl.gov ( 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU ( 39 ms 39 ms 19 ms
3 lilac-dmc.Berkeley.EDU ( 39 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU ( 39 ms 40 ms 39 ms
5 ccn-nerif22.Berkeley.EDU ( 39 ms 39 ms 39 ms
6 ( 40 ms 59 ms 59 ms
7 ( 59 ms 59 ms 59 ms
8 ( 99 ms 99 ms 80 ms
9 ( 139 ms 239 ms 319 ms
10 ( 220 ms 199 ms 199 ms
11 nic.merit.edu ( 239 ms 239 ms 239 ms

Note that lines 2 & 3 are the same. This is due to a
buggy kernel on the 2nd hop system – lbl-csam.arpa – that
forwards packets with a zero ttl (a bug in the distributed
version of 4.3BSD). Note that you have to guess what path
the packets are taking cross-country since the NSFNet
(129.140) doesn’t supply address-to-name translations for
its NSSes.

A more interesting example is:

[yak 72]% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (, 30 hops max
1 helios.ee.lbl.gov ( 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU ( 19 ms 19 ms 19 ms
3 lilac-dmc.Berkeley.EDU ( 39 ms 19 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU ( 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU ( 20 ms 39 ms 39 ms
6 ( 59 ms 119 ms 39 ms
7 ( 59 ms 59 ms 39 ms
8 ( 80 ms 79 ms 99 ms
9 ( 139 ms 139 ms 159 ms
10 ( 199 ms 180 ms 300 ms
11 ( 300 ms 239 ms 239 ms
12 * * *
13 ( 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU ( 339 ms 279 ms 279 ms

Note that the gateways 12, 14, 15, 16 & 17 hops away
either don’t send ICMP „time exceeded“ messages or send
them with a ttl too small to reach us. 14 – 17 are run-
ning the MIT C Gateway code that doesn’t send „time
exceeded“s. God only knows what’s going on with 12.

The silent gateway 12 in the above may be the result of a
bug in the 4.[23]BSD network code (and its derivatives):
4.x (x < = 3) sends an unreachable message using whatever ttl remains in the original datagram. Since, for gate- ways, the remaining ttl is zero, the ICMP "time exceeded" is guaranteed to not make it back to us. The behavior of this bug is slightly more interesting when it appears on the destination system: 1 helios.ee.lbl.gov ( 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU ( 39 ms 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU ( 19 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU ( 39 ms 40 ms 19 ms 5 ccn-nerif35.Berkeley.EDU ( 39 ms 39 ms 39 ms 6 csgw.Berkeley.EDU ( 39 ms 59 ms 39 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU ( 59 ms ! 39 ms ! 39 ms ! Notice that there are 12 "gateways" (13 is the final des- tination) and exactly the last half of them are "missing". What's really happening is that rip (a Sun-3 running Sun OS3.5) is using the ttl from our arriving datagram as the ttl in its ICMP reply. So, the reply will time out on the return path (with no notice sent to anyone since ICMP's aren't sent for ICMP's) until we probe with a ttl that's at least twice the path length. I.e., rip is really only 7 hops away. A reply that returns with a ttl of 1 is a clue this problem exists. Traceroute prints a "!" after the time if the ttl is <= 1. Since vendors ship a lot of obsolete (DEC's Ultrix, Sun 3.x) or non-standard (HPUX) software, expect to see this problem frequently and/or take care picking the target host of your probes. Other possible annotations after the time are !H, !N, or !P (got a host, network or protocol unreachable, respec- tively), !S or !F (source route failed or fragmentation needed - neither of these should ever occur and the asso- ciated gateway is busted if you see one), !X (communica- tion administratively prohibited), or ! (ICMP unreach- able code N). If almost all the probes result in some kind of unreachable, traceroute will give up and exit. This program is intended for use in network testing, mea- surement and management. It should be used primarily for manual fault isolation. Because of the load it could impose on the network, it is unwise to use traceroute dur- ing normal operations or from automated scripts. SEE ALSO netstat(1), ping(8)


Implemented by Van Jacobson from a suggestion by Steve
Deering. Debugged by a cast of thousands with particu-
larly cogent suggestions or fixes from C. Philip Wood, Tim
Seaver and Ken Adelman.

The current version is available via anonymous ftp:



Please send bug reports to traceroute@ee.lbl.gov.

27 September 1996


Rbcafe » Unix



rpc.lockd — NFS file locking daemon


rpc.lockd [-d debug_level] [-g grace period] [-x statd cache period]


The rpc.lockd utility provides monitored and unmonitored file and record
locking services in an NFS environment. To monitor the status of hosts
requesting locks, the locking daemon typically operates in conjunction
with rpc.statd(8).

Options and operands available for rpc.lockd:

-d The -d option causes debugging information to be written to sys-
log, recording all RPC transactions to the daemon. These mes-
sages are logged with level LOG_DEBUG and facility LOG_DAEMON.
Specifying a debug_level of 1 results in the generation of one
log line per protocol operation. Higher debug levels can be
specified, causing display of operation arguments and internal
operations of the daemon.

-g The -g option allow to specify the grace period, in seconds.
During the grace period rpc.lockd only accepts requests from
hosts which are reinitialising locks which existed before the
server restart. Default is 30 seconds.

-w The -w option tells rpc.lockd to wait until the first client
locking request is made before starting the locking daemon(s).
This may be used on NFS clients to defer starting the NFS locking
daemons until it is known that they will be needed. (Note:
rpc.statd(8) will also be started if it isn’t already running)

-x The -x option tells rpc.lockd how long to cache state records for
contacting client rpc.statd(8) implementations. Setting it to
zero will disable the cache which will make lock and unlock
requests from a single client more expensive because of addi-
tional interaction with the client’s statd. The default cache
time is 60 seconds.

Error conditions are logged to syslog, irrespective of the debug level,
using log level LOG_ERR and facility LOG_DAEMON.

The rpc.lockd utility must NOT be invoked by inetd(8) because the proto-
col assumes that the daemon will run from system start time. Instead, it
should be configured in rc.conf(5) to run at system startup.


/usr/include/rpcsvc/nlm_prot.x RPC protocol specification for the network lock manager protocol.


Updated: Donnerstag, 18UTCThu, 18 Aug 2016 13:07:29 +0000 18. August 2016 — 1:07

Rbcafe » Unix

Ripe MD

Ripe MD

RIPEMD160, RIPEMD160_Init, RIPEMD160_Update, RIPEMD160_Final –
RIPEMD-160 hash function


#include (openssl/ripemd.h)

unsigned char *RIPEMD160(const unsigned char *d, unsigned long n,
unsigned char *md);

void RIPEMD160_Init(RIPEMD160_CTX *c);
void RIPEMD160_Update(RIPEMD_CTX *c, const void *data,
unsigned long len);
void RIPEMD160_Final(unsigned char *md, RIPEMD160_CTX *c);


RIPEMD-160 is a cryptographic hash function with a 160 bit output.

RIPEMD160() computes the RIPEMD-160 message digest of the n bytes at d
and places it in md (which must have space for RIPEMD160_DIGEST_LENGTH
== 20 bytes of output). If md is NULL, the digest is placed in a static

The following functions may be used if the message is not completely
stored in memory:

RIPEMD160_Init() initializes a RIPEMD160_CTX structure.

RIPEMD160_Update() can be called repeatedly with chunks of the message
to be hashed (len bytes at data).

RIPEMD160_Final() places the message digest in md, which must have
space for RIPEMD160_DIGEST_LENGTH == 20 bytes of output, and erases the

Applications should use the higher level functions EVP_DigestInit(3)
etc. instead of calling the hash functions directly.


RIPEMD160() returns a pointer to the hash value.
RIPEMD160_Init(), RIPEMD160_Update() and RIPEMD160_Final() do not
return values.


ISO/IEC 10118-3 (draft) (??)


Rbcafe » Unix



RC4_set_key, RC4 – RC4 encryption


#include (openssl/rc4.h)

void RC4_set_key(RC4_KEY *key, int len, const unsigned char *data);

void RC4(RC4_KEY *key, unsigned long len, const unsigned char *indata,
unsigned char *outdata);


This library implements the Alleged RC4 cipher, which is described for
example in Applied Cryptography. It is believed to be compatible with
RC4[TM], a proprietary cipher of RSA Security Inc.

RC4 is a stream cipher with variable key length. Typically, 128 bit
(16 byte) keys are used for strong encryption, but shorter insecure key
sizes have been widely used due to export restrictions.

RC4 consists of a key setup phase and the actual encryption or decryp-
tion phase.

RC4_set_key() sets up the RC4_KEY key using the len bytes long key at

RC4() encrypts or decrypts the len bytes of data at indata using key
and places the result at outdata. Repeated RC4() calls with the same
key yield a continuous key stream.

Since RC4 is a stream cipher (the input is XORed with a pseudo-random
key stream to produce the output), decryption uses the same function
calls as encryption.

Applications should use the higher level functions EVP_EncryptInit(3)
etc. instead of calling the RC4 functions directly.


RC4_set_key() and RC4() do not return values.


Certain conditions have to be observed to securely use stream ciphers.
It is not permissible to perform multiple encryptions using the same
key stream.


Rbcafe » Unix



ping – send ICMP ECHO_REQUEST packets to network hosts


ping [-dfnqrvR] [-c count] [-i wait] [-l preload] [-p pattern] [-s


Ping uses the ICMP protocol’s mandatory ECHO_REQUEST datagram to elicit
an ICMP ECHO_RESPONSE from a host or gateway. ECHO_REQUEST datagrams
(„pings“) have an IP and ICMP header, followed by a „struct timeval“
and then an arbitrary number of „pad“ bytes used to fill out the pack-
et. The options are as follows: Other options are:

-c count
Stop after sending (and receiving) count ECHO_RESPONSE packets.

-d Set the SO_DEBUG option on the socket being used.

-f Flood ping. Outputs packets as fast as they come back or one
hundred times per second, whichever is more. For every
ECHO_REQUEST sent a period „.“ is printed, while for ever
ECHO_REPLY received a backspace is printed. This provides a
rapid display of how many packets are being dropped. Only the
super-user may use this option. This can be very hard on a net-
work and should be used with caution.

-i wait
Wait wait seconds between sending each packet. The default is to
wait for one second between each packet. This option is incom-
patible with the -f option.

-l preload
If preload is specified, ping sends that many packets as fast as
possible before falling into its normal mode of behavior. Only
the super-user may use this option.

-n Numeric output only. No attempt will be made to lookup symbolic
names for host addresses.

-p pattern
You may specify up to 16 „pad“ bytes to fill out the packet you
send. This is useful for diagnosing data-dependent problems in a
network. For example, „-p ff“ will cause the sent packet to be
filled with all ones.

-q Quiet output. Nothing is displayed except the summary lines at
startup time and when finished.

-R Record route. Includes the RECORD_ROUTE option in the
ECHO_REQUEST packet and displays the route buffer on returned
packets. Note that the IP header is only large enough for nine
such routes. Many hosts ignore or discard this option.

-r Bypass the normal routing tables and send directly to a host on
an attached network. If the host is not on a directly-attached
network, an error is returned. This option can be used to ping a
local host through an interface that has no route through it
(e.g., after the interface was dropped by routed(8)).

-s packetsize
Specifies the number of data bytes to be sent. The default is
56, which translates into 64 ICMP data bytes when combined with
the 8 bytes of ICMP header data.

-v Verbose output. ICMP packets other than ECHO_RESPONSE that are
received are listed.

When using ping for fault isolation, it should first be run on the local
host, to verify that the local network interface is up and running.
Then, hosts and gateways further and further away should be „pinged“.
Round-trip times and packet loss statistics are computed. If duplicate
packets are received, they are not included in the packet loss calcula-
tion, although the round trip time of these packets is used in calculat-
ing the minimum/average/maximum round-trip time numbers. When the speci-
fied number of packets have been sent (and received) or if the program is
terminated with a SIGINT, a brief summary is displayed.

If ping does not receive any reply packets at all it will exit with code
1. On error it exits with code 2. Otherwise it exits with code 0. This
makes it possible to use the exit code to see if a host is alive or not.

This program is intended for use in network testing, measurement and man-
agement. Because of the load it can impose on the network, it is unwise
to use ping during normal operations or from automated scripts.


An IP header without options is 20 bytes. An ICMP ECHO_REQUEST packet
contains an additional 8 bytes worth of ICMP header followed by an arbi-
trary amount of data. When a packetsize is given, this indicated the
size of this extra piece of data (the default is 56). Thus the amount of
data received inside of an IP packet of type ICMP ECHO_REPLY will always
be 8 bytes more than the requested data space (the ICMP header).

If the data space is at least eight bytes large, ping uses the first
eight bytes of this space to include a timestamp which it uses in the
computation of round trip times. If less than eight bytes of pad are
specified, no round trip times are given.


Ping will report duplicate and damaged packets. Duplicate packets should
never occur, and seem to be caused by inappropriate link-level retrans-
missions. Duplicates may occur in many situations and are rarely (if ev-
er) a good sign, although the presence of low levels of duplicates may
not always be cause for alarm.

Damaged packets are obviously serious cause for alarm and often indicate
broken hardware somewhere in the ping packet’s path (in the network or in
the hosts).


The (inter)network layer should never treat packets differently depending
on the data contained in the data portion. Unfortunately, data-dependent
problems have been known to sneak into networks and remain undetected for
long periods of time. In many cases the particular pattern that will
have problems is something that doesn’t have sufficient „transitions“,
such as all ones or all zeros, or a pattern right at the edge, such as
almost all zeros. It isn’t necessarily enough to specify a data pattern
of all zeros (for example) on the command line because the pattern that
is of interest is at the data link level, and the relationship between
what you type and what the controllers transmit can be complicated.

This means that if you have a data-dependent problem you will probably
have to do a lot of testing to find it. If you are lucky, you may manage
to find a file that either can’t be sent across your network or that
takes much longer to transfer than other similar length files. You can
then examine this file for repeated patterns that you can test using the
-p option of ping.


The TTL value of an IP packet represents the maximum number of IP routers
that the packet can go through before being thrown away. In current
practice you can expect each router in the Internet to decrement the TTL
field by exactly one.

The TCP/IP specification states that the TTL field for TCP packets should
be set to 60, but many systems use smaller values (4.3 BSD uses 30, 4.2
used 15).

The maximum possible value of this field is 255, and most Unix systems
set the TTL field of ICMP ECHO_REQUEST packets to 255. This is why you
will find you can „ping“ some hosts, but not reach them with telnet(1)
or ftp(1).

In normal operation ping prints the ttl value from the packet it re-
ceives. When a remote system receives a ping packet, it can do one of
three things with the TTL field in its response:

+o Not change it; this is what Berkeley Unix systems did before the
4.3BSD-Tahoe release. In this case the TTL value in the received
packet will be 255 minus the number of routers in the round-trip

+o Set it to 255; this is what current Berkeley Unix systems do. In
this case the TTL value in the received packet will be 255 minus the
number of routers in the path from the remote system to the pinging

+o Set it to some other value. Some machines use the same value for
ICMP packets that they use for TCP packets, for example either 30 or
60. Others may use completely wild values.


Many Hosts and Gateways ignore the RECORD_ROUTE option.

The maximum IP header length is too small for options like RECORD_ROUTE
to be completely useful. There’s not much that that can be done about
this, however.

Flood pinging is not recommended in general, and flood pinging the broad-
cast address should only be done under very controlled conditions.


netstat(1), ifconfig(8), routed(8)


The ping command appeared in 4.3BSD.


Updated: Donnerstag, 18UTCThu, 18 Aug 2016 12:53:10 +0000 18. August 2016 — 12:53

Rbcafe » Unix



nfsiod — local NFS asynchronous I/O server


nfsiod [-n num_servers]


Nfsiod runs on an NFS client machine to service asynchronous I/O requests
to its server. It improves performance but is not required for correct

Unless otherwise specified, a single server is started.

The options are as follows:

-n Specify how many servers are to be started.

A client should run enough servers to handle its maximum level of concur-
rency, typically four to six. Each server runs as a separate thread
within the nfsiod process.

The nfsiod utility exits 0 on success, and >0 if an error occurs.


Rbcafe » Unix




netstat-nat [options]


netstat-nat Displays NAT connections managed by netfilter/iptables which comes with the > 2.4.x linux kernels.

The program reads its information from ‚/proc/net/ip_conntrack‘, which is the temporary conntrack-storage of netfilter.


displays help
don’t resolve IPs/portnumbers to host/portnames
display NAT connections with protocol selection (see /etc/protocols)
display connections by source IP/hostname
display connections by destination IP/hostname
display SNAT connections
display DNAT connections
display only connections to NAT box self (doesn’t show SNAT & DNAT)
extended view of hostnames
sort connections
no output header
prints version






netstat-nat has been written by D.Wijsman danny@tweegy.demon.nl
The manual page has been written by marceln@xs4all.nl


Updated: Donnerstag, 18UTCThu, 18 Aug 2016 13:05:38 +0000 18. August 2016 — 1:05
Seite 1 von 41234
Rbcafe © 2004- | Rb Cafe 1.3 | Kontakt Rbcafe | Rbcafe auf Twitter | Rbcafe auf Facebook | Datenschutz