COLD(1)

NAME
cold - Computerized Ordinary LAN Dumper 1.0.10

SYNOPSIS
cold [-hneaimsfd] [--[help][notpromiscuous][hex][ascii]] [--[interface] device] [--[maxpackets] n] [--[snaplen] n] [--flush] [--isdn]

DESCRIPTION
Cold is a network sniffer and protocol analyzer. A sniffer is a network analyzing package with extracts data frames from a local network and exerpt useful information about the transported information and protocol structure. Cold is designed to grab data frames from any selected network device in a Unix box. This application has been developed for troubleshooting, educational and commercial purposes only.

When cold is run on an ethernet (don't forget to be in promiscuous mode) it is able to see all of the frames of that collision domain. In other words if you have a non-swithed hub-based (or coaxial) network cold will catch all of the traffic. Otherwise, if the network is switched, cold will naturally be able to see only the data flowing on the collision domain of the ethernet adapter. Don't forget about this. Fortunately some switch vendors (Cisco is an example) sell switches where a port may be configured to 'see' all of the traffic. At least you will not need to mess up with cables.

Even if network sniffers are extremely useful for network troubleshooters and nifty programs to use, they are extremely dangerous since they enable non-expert users with root privileges to gain sensible informations (like passwords and such) flowing on your network. The solution is simple: use switches and don't set the suid bit on cold if you don't like troubles.

Currently cold supports only some protocols (802.3 MAC, 802.2 LLC, 802.5 TOKEN RING, 802.1D BPDU, SNAP, NETBIOS, IPX, ARP, IP, ICMP, TCP, UDP) but most of them are implemented in a rather detailed manner.

Information has been taken from a lot of sources: IEEE, IANA, freely available technical reports from Cisco, Cabletron, Novell, IBM, Microsoft, internet Requests for Comments (RFC792, RFC826, RFC1042, RFC1112, RFC1340, RFC1466, RFC1548, RFC1700, RFC2153), and many useful WEB pages and books. A list of more than 2000 ethernet card manifacturers is included within the package. The collecting of OUI codes (Organization Unique Identifier) was rather difficult. Many thanks to Michael A. Patton, Internet Consultant, for his work in maintaining one of the best OUI codes list.

Currently only the Linux executable version of Cold is available, compiled on a Linux 2.0.33[Pentium]. The source code is anyway rather portable and well designed and so the creation of other executable versions should be easy. If you can give support to create other versions just mail the author.

This program is Free Software, so you can use it as much as you like and give it to anyone, provided you will not charge anything. Lots of work is anyway still to be done, so usage reports, ideas and contributions are really welcome.

A mailing list for cold users is available. Just send an email to majordomo@panservice.it with "subscribe cold" in the body of the message.

Cold official home page is available at http://www.panservice.it/cold

OPTIONS

-h, --help
    Print simple usage information.

-i device, --interface device
    Allows to specify which interface to listen to. Normally an ethernet interface will be specified here (like eth0, eth1, eth2, etc.) but a pppX or lo (loopback) device may be specified too. Also Token Ring (trX) and ISDN (isdnX) may be used.

-n, --notpromiscuous
    Ethernet devices are opened in promiscuous mode by default. This option allows to open in non-promiscuous mode. When an ethernet adapter is in promiscuous mode it listens to all of the packets flowing on the network, when it is NOT in promiscuous mode, it will listen only to the packets directed to itself. Warning: if the interface is already in promiscuous mode for some other reason this option has no effect.

-m num, --maxpackets num
    Make the sniffer stop after 'num' packets have arrived. The default is to loop forever (A value of 0 for num is the same). It is possible anyway to stop the sniffer using CTRL-C or sending a -HUP signal.

-e, --hex
    Print the hex dump of every received packet

-a, --ascii
    Print an ASCII dump of every received packet. Characters outside the 0x20-0x7E range are printed as dots '.'.

-s, --snaplen
    Selects the bytes_per_frame capture size. Default is 1516. Warning: Token Ring has much longer frames.

-f, --flush
    Flushes stdout buffer after each packet.

-d, --isdn
    When sniffing an isdnX device the libcap consider that as a normal Ethernet device. The problem is that the packets are not standard Ethernet packets but RawIP encapsulated data. This option forces the sniffer to consider the interface as a RawIP device.

EXAMPLE

cold -i eth1

cold monitors all packets on the eth1 interface, listening to all packets (since promiscuous mode is enabled by default), and extracting all possible information, but no ASCII or HEX dump.

CONVENTIONS
All values are printed in decimal. If a different number base is used, it is clearly shown, for example prepending 0x to hexadecimal values.

PACKET DATA HINTS
Cold prints as much data as possible for every packet. The different frame parts are clearly shown. This section of the manual page will give you some hints on the different parts you could see.

PKT - New packet arrived

An incoming packet starts with this:
 [PKT]
 PKT: Frame: number 42, size 60 of 60, arrived at 903543604.829889 For each arriving packet several informations are shown. Here you can see a sequential frame number, the frame size and the time of arrival, expressed in seconds.microseconds. The frame number isn't contained in the packed but it is created and printed by the software to help managing long captures. The frame size shows how many bytes have been captured of the total packet length.

MAC - Medium Access Control (IEEE 802.3 Ethernet Frame)

Ethernet Frames are transported at the MAC (Medium Access Control) level. An 802.3 frame looks like this:
 [MAC - Ethernet Frame]
 MAC: Source: 00-c0-df-e0-b5-d6, KYE SYSTEMS CORP., Individual/Universal
 MAC: Dest: 00-e0-1e-b9-16-37, CISCO SYSTEMS, Individual/Universal
 MAC: Protocol = 0x0800, DOD IP The MAC addressess of the sending and receiving network adapters are printed, including the manufacturers (based on Organization Unique Identifier), and some characterization of the address, like if it is an Individual or Group address, or if it is an Universal or LocalAssigned address. Some proprietary multicast addresses are indicated too. At last the carried protocol is printed. The carried protocol maybe a standard protocol or an IEEE802.3 packet length field.

LLC - Logical Link Control (IEEE 802.2 Frame)

Data can be transported in LLC packets. An 802.2 frame looks like this:
 [LLC 802.2 Frame]
 LLC: DSAP = 0xf0, Individual, User defined, IBM - Netbios
 LLC: SSAP = 0xf0, Command, User defined, --unknown--
 LLC: U-Frame: unknown, Final For each LLC packet received the DSAP (Destination Service Access Point) and SSAP (Source Service Access Point) are printed. The DSAP may be a Group or Individual adrress, while the SSAP maybe a Command or a Response. Both DSAP or SSAP may be User defined or IEEE defined, and several definitions are detected. The LLC frame maybe an Unnumbered Information (U), Supervisory (S) or Information (I) Frame. Lots of flags about these frames are reported. An LLC frame can carry directly several protocols, like IP, NetBIOS, IPX. An LLC fram can also be a SNAP (SubNetwork Access Protocol) packet, which may carry standard or proprietary protocols. If a standard protocol is supported it is correctly dumped. A SNAP frame looks like this:
 [SNAP]
 SNAP: OUI: 0x000000, Protocol 0x80f3, AppleTalk AARP (Kinetics)

NetBIOS - Network Basic Input Output System

NetBIOS is IBM's Network BIOS. A NetBIOS frame appears like this:
 [NetBIOS Frame]
 NETB: Header length: 44
 NETB: Delimiter: 0xefff
 NETB: Command: 0x08, DATAGRAM (Application program-generated datagram)
 NETB: Data: 0x00/0x0000
 NETB: Transmit/Response correlator: 0x0000/0x0000
 NETB: Frame type: Non session (UI format)
 NETB: Destination name: [PANSERVICE .]
 NETB: Source name: [HELPDESK .] Some support of NetBIOS frames is included in this package. For every received frame various packet attributes are printed, including the Command and Frame types, and the Source and Destination of the packet. Notice that NetBIOS usually carries other protocols on its top (like SMB).

IPX - Internet Packet Exchange

IPX is Novell's network-layer protocol. An IPX frame appears in this way:
 [IPX Frame]
 IPX: Checksum: 0xffff
 IPX: Length: 34
 IPX: Transport control: 0x00
 IPX: Packet type: 17, NCP - NetWare Core Protocol
 IPX: Destination Net: 0x00000000 Host: 0xffffffffffff
 IPX: Destination Socket: 0x0452, SAP (Service Advertisement Protocol)
 IPX: Source Net: 0x00000000 Host: 0x00c0dfa05797
 IPX: Source Socket: 0x4008, unknown Some support of IPX is included in this package. For every frame received various informations are printed, including the Packet type, destination and source host, net and socket. You will generally see other protocols (ex. SMB) on top of IPX.

ARP - Address Resolution Protocol

ARP stands for Address Resolution Protocol. Using ARP a device on a network can, for example, search for another device's physical address just knowing its IP address. An ARP frame looks like this:
 [ARP Frame]
 ARP: Hardware type = 1, Ethernet (10Mb)
 ARP: Protocol = 0x0800, DOD IP
 ARP: Length of hardware address = 6 bytes
 ARP: Length of protocol address = 4 bytes
 ARP: Operation = 2, REPLY
 ARP: Sender's hardware address = 00-40-33-ca-8e-e0 ADDTRON TECHNOLOHY CO.
 ARP: Sender's protocol address = [194.247.170.116] Class C
 ARP: Target hardware address = 00-c0-df-aa-20-08 KYE SYSTEMS CORP.
 ARP: Target protocol address = [194.247.170.126] Class C Several fields are printed, like the hardware type, the protocol used and the relative address size, the type of operation (REQUEST, REPLY, ecc.), and the addressess of the involved devices.

BPDU - 802.1D Bridge Protocol Data Unit

Bridge PDUs are used by ethernet bridges for the computation of the spanning tree. A typical bridge PDU looks like this:
 [Bridge PDU]
 BPDU: Protocol identifier: 0x0000
 BPDU: Protocol version: 0x00
 BPDU: Type: 0x00, configuration
 BPDU: Flags: 0x00
 BPDU: Root priority: 0x8000
 BPDU: Root ID: 0x00c049027bb6, US Robotics Total Control NET Server Card
 BPDU: Root path cost: 10
 BPDU: Bridge priority: 0x8000
 BPDU: Bridge ID: 0x00c049030db6, US Robortics Total Control NET Server Card
 BPDU: Port identifier: 0x800e (priority/identifier)
 BPDU: Message age: 1024 msec
 BPDU: Max age: 20480 msec
 BPDU: Hello time: 2048 msec
 BPDU: Forward delay: 15360 msec The root path cost is the path cost needed to reach the root bridge. The Port Identifier is plit in two fields: the first byte is the priority, the second is the port number. Then the timings follow. The values are shown in milliseconds, considering 1 unit = 4 msec (other sources suggest 1 unit = 0.5 msec). The Max Age is the lifetime of the BPDU. The Hello time is the interval between BPDUs.

IP - Internet Protocol frames

(manual section still to be written)

ICMP - Internet Control Message Protocol

An ICMP packet looks like this.
 [ICMP Frame]
 ICMP: Type = 8, Echo Request
 ICMP: Code = 0, ?
 ICMP: Checksum = 0x3343
 ICMP: Id = 0x3f35
 ICMP: Sequence = 0 ICMP packets are used to track down problems on an IP network. Different kinds of ICMP packets will be shown in different ways. The more common ICMP packets are Echo Request, Echo Reply and Redirect.

TCP - Transmission Control Protocol

(manual section still to be written)

UDP - Unreliable Data Protocol

(manual section still to be written)

Token Ring - 802.5 protocol

Sniffing on a Token Ring (802.5) network you will get something like this:
 [Token Ring 802.5 Frame]
 TR: Priority = 0, not a token, monitor
 TR: Reserved = 0x0
 TR: Frame type = 0x4, LLC-PDU
 TR: Reserved = 0x00
 TR: Destination = 0x0004acff24e2
 TR: Source = 0x0009d4a90003
 TR: No routing information field Token Ring is able to carry other protocols on top of it. The sniffer is able to print out some token ring parameters, even if in a not detailed manner. For example token ring Routing and Major Vectors IDs, are not handled, cause of documentation leakage.

Anyway the sniffer is able to identify and expand correctly transported LLC PDUs, which may contain, for example, SNAP and IP data packets.

IMPORTANT: Token Ring frames are longer than ethernet ones. You will need to increase the default snaplen.

[Unable to unroll this protocol...]

Sometimes you will see something like this:
 [Unable to unroll this protocol: 0x6004, DEC Local Area Transport] This message is printed when a non-supported protocol is found. If you've tech details about that protocol, please mail to the author, including the protocol number, description and hex dumps.

It is not easy to collect data about so many protocols. If you would like to see support for other protocols, just contact the author. Maybe the documentation and devices you could access are really valuable.

SEE ALSO

ping(8), traceroute(8), arp(8), icmpinfo(1), netstat(1), tcpdump

AUTHOR

Giuliano Claudio Peritore, <g.peritore@panservice.it> of Panservice http://www.panservice.it and of Flashnet Telecomunicazioni SpA http://www.flashnet.it

Cold is built on top of the libpcap packet capture library, written by Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.

Thanks to Silvano Gai (Politecnico di Torino), Piero Nicoletti (Internet Consultant), Pier Luca Montessoro (Universita' degli studi di Udine) for their book "RETI LOCALI, dal cablaggio all'internetworking", whose help was really valuable.

BETA TESTERS

Thanks to Alessio Marinelli (Bristol-Myers Squibb) for his help during the testing of the Token Ring protocol implementation functionalities.

CONTRIBUTORS

Thanks to Patrick Schaaf and Edwin Cremer for their suggestions.

COPYRIGHT

Copyright (c) Giuliano Claudio Peritore 1995, 1996, 1997, 1998, All rights reserved.

BUGS

This programs is rather complex, so there are bugs. Most of them should be located in network to host byte ordering or in RFCs and standards not completely implemented (yet). If you discover a bug please send me an email to g.peritore@panservice.it with most of the details (Hex dumps are higly welcomed).