spp man page on DragonFly

Man page or keyword search:  
man Server   44335 pages
apropos Keyword Search (all sections)
Output format
DragonFly logo
[printable version]

SPP(1)				 User Manuals				SPP(1)

NAME
       spp  - calculates round trip time (RTT) from pcap files or live traffic
       capture

SYNOPSIS
   File processing:
       spp -a address -A address -f file -F file [-# hashcode | -n  address  |
       -N address |-p|-c|-m|-b]

   Live processing master:
       spp -a address -A address (-i interface | -r host ) ( -I interface | -R
       slave_host  )  [-#  hashcode  |-g  usec	|  -n  address	|  -N  address
       |-p|-c|-m|-b]

   Remote slave:
       spp  -a	address -A address -s master_host -I interface [ -# hashcode |
       -g usec | -l no.bytes | -t seconds | -n address | -N address ]

   Output:
       [pair count] timestamp rtt [spt]

DESCRIPTION
       spp provides frequently updated RTT estimates using IP traffic  already
       present	in  the network. spp estimates the RTT between two measurement
       points without requiring precise time synchronisation  between  points.
       spp accurately estimates the RTT experienced by any application's traf‐
       fic without needing modifications to  the  application  itself  or  the
       routers along the path.

       spp  requires  a capture of traffic at both ends of the path that is to
       be measured. From these captures spp can create	synthetic  pairs  from
       which  RTT  can be calculated. spp works with tcpdump/pcap files previ‐
       ously captured at two points on a network, or alternatively, live  cap‐
       ture on local and/or remote interfaces may be used.

       The  reference  point  is  where the trip is considered to have started
       from, with the monitor point being the far end of the trip. To clarify,
       when  using  ping,  you would execute the ping from the reference point
       and the ping target would be the monitor point.

OPTIONS
   General Options:
       -a     IP address near the reference point

       -A     IP address near the monitor point

       -n     NAT IP address near the reference point

       -N     NAT IP address near the monitor point

       -s     Put into slave mode and send to the master specified

       -o     Offset in seconds of clocks at the monitor point with respect to
	      the reference point.

       -d     Max difference of timestamps in seconds allowed between matching
	      packets.	This value should be greater than expected  RTT	 (plus
	      any  clock offset when not specifying a fixed offset with the -o
	      option).. (Default: 60)

       -G     Maximum number of packets that will be searched to match a  pair
	      before giving up (Default: 10000(pcap file) or 500(live))

       -v     Verbosity Level (Default: 0)
		  Determines information that is displayed on the console.
		  The verbosity level is the total of the IDs of each required
		  detail as listed below:
		      1 Queue Size
		      2 Thread Details
		      4 Pair Info
		      8 Record Info
		      16 Instance Info
		      32 Packet Info
		      64 RTT COUNT - "checksum"
		      128 Network Details
		      1024 Verbose Network Details

   Source options:
       -f     File to be read for the reference point (PCAP format)

       -F     File to be read for the monitor point (PCAP format)

       -i     Reference	 point	live capture interface (Except for when acting
	      as a slave - instead use -I)

       -I     Monitor point live capture interface (Also  used	for  reference
	      point acting as a slave)

   Network options:
       -l     Length of the timestamp field in bytes [1 - 4] (Default: 2)

       -g     Granularity of timestamps in microseconds (Default: 100)

       -t     Network  update  timeout - Maximum time in seconds between slave
	      sending spp sample frames to the master (Default: 1)

   Output options:
       -p     Output 'Server Processing Times' (The time between matched pack‐
	      ets seen at the monitor point)

       -c     Output 'Pair Count' (Running total of pairs the program has gen‐
	      erated)

       -m     Calculate timestamps from monitor point clock  rather  than  the
	      reference	 point clock (Output timestamps are the average of the
	      packet's timestamps that were combined to make the pair)

       -b     Set the timestamp to the time that the first packet of the  pair
	      was first seen. (This is useful when comparing spp output to the
	      raw trace files).

   Packet Matching Options:
       -#     The # option maybe used to set which  fields  are	 used  in  the
	      packet matching process (Default: 63).
		      The  value  of  <code>  is the total of all the required
	      field IDs as listed below:
		      IP fields:
				      1 Source Address
				      2 Destination Address
				      4 Protocol
				      8 Identification
		      TCP/UDP fields:
				      16 Source Port
				      32 Destination Port
		      TCP fields:
				      64 Sequence Number
				      128 Acknowledgement Number
				      256 Data offset, flags, window size
				      512 Checksum, urgent pointer
		      UDP Fields:
				      1024 Length, checksum
				      2048 Up to 12 bytes UDP data (limited by
	      packet length)
		      Not UDP/TCP:
				      4096  Up	to  20	bytes  after IP header
	      (limited by packet length)

	      NOTE: When NAT is use, source and destination IP address	fields
	      will be omitted from hashes automatically.

EXAMPLES
   1. From pcap files
       The  IP	at  the	 reference point is 10.0.0.1 and the IP at the monitor
       point is 10.0.0.2. The files /data/ref.pcap and /data/mon.pcap  contain
       data  captured  at  the reference and monitor points respectively. Note
       that the display of pair count and server  processing  times  are  also
       enabled:

       spp -f /data/ref.pcap -a 10.0.0.1 -F /data/mon.pcap -A 10.0.0.2 -s -c

   2. Local live capture
       Processing  RTT	in rear realtime from two local interfaces. This would
       be useful in a lab environment  when  testing  equipment	 or  networks.
       There are two local interfaces (em0 and em1) with IP addresses 10.0.1.1
       and 10.0.2.1 respectively. The reference point will be em0 (10.0.1.1).

       spp -i em0 -a 10.0.1.1 -I em1 -A 10.0.2.1

   3. Local/Remote with in band hash transmission
       Processing RTT in near realtime from a local interface at the reference
       point  and remote interface at the monitor point. This example uses 'in
       band' hash transmission.

       The master is running at the reference point and is  capturing  on  the
       interface em0 (Interface address 10.0.0.1). The slave is running at the
       monitor point, capturing	 on  the  bge0	interface  (Interface  address
       10.0.0.2).

       On the master:

       spp -i em0 -a 10.0.0.1 -R 10.0.0.2 -A 10.0.0.2

       On the slave:

       spp -s 10.0.0.1 -a 10.0.0.1 -I bge0 -A 10.0.0.2

   4. Local/Remote with out of band hash transmission
       Processing RTT in near realtime from a local interface at the reference
       point and remote interface at the monitor point. This example uses 'out
       of band' hash transmission.

       This is the same as the previous example except that the hashes will be
       sent across a separate network to that which  is	 being	measured.  The
       interfaces  to  this  network  have  IP	addresses  of  192.168.0.1 and
       192.168.0.2 at the reference and monitor points respectively.

       On the master:

       spp -i em0 -a 10.0.0.1 -R 192.168.0.2 -A 10.0.0.2

       On the slave:

       spp -s 192.168.0.1 -a 10.0.0.1 -I bge0 -A 10.0.0.2

   5. From files with NAT
       The IP at the reference point is 10.0.0.1 and the  IP  at  the  monitor
       point is 136.0.0.2. The files /data/ref.pcap and /data/mon.pcap contain
       data captured at the reference and  monitor  points  respectively.  The
       reference  point is behind NAT.	To the outside world, it appears to be
       136.0.0.1

       spp -f /data/ref.pcap -a 10.0.0.1 -n  136.0.0.1	-F  /data/mon.pcap  -A
       136.0.0.2

BUGS
       Live remote capture has not been tested much and may have bugs.

AUTHOR
       Amiel Heyde <amiel at swin dot edu dot au> Centre for Advanced Internet
       Architectures, Swinburne University of Technology, Melbourne, Australia

CONTRIBUTORS
       Software designed in collaboration with Grenville  Armitage  <garmitage
       at  swin	 dot  edu  dot au> Centre for Advanced Internet Architectures,
       Swinburne University of Technology, Melbourne, Australia

       Original implementation extended and revised by David Hayes <dahayes at
       swin  dot edu dot au>, Atwin O. Calchand <acalchand at swin dot edu dot
       au>, Christopher Holman, Sebastian Zander <szander at swin dot edu  dot
       au>,  Centre  for Advanced Internet Architectures, Swinburne University
       of Technology, Melbourne, Australia

SEE ALSO
       pcap(3), tcpdump(8)

FreeBSD				   MAY 2013				SPP(1)
[top]

List of man pages available for DragonFly

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net