Tim's packet zoo

This web page provides a collection of packets that demonstrate a variety of network protocols. They are intended to be used as learning aids, and come from a variety of sources as noted in credits. They are loosely organised according to the highest interesting protocol that they capture, though of course higher layer protocols are encapsulated by lower layer protocols. They are in standard pcap format, and can be viewed using tools like Wireshark or online with Cloudshark.

Other Sources of Capture Files.


Link layer: Ethernet IEEE 802.11 USB Firewire / IEEE 1394 Powerline / BPL Zigbee ATM
Spanning Tree Protocol 802.1Q virtual lans GVRP Link-layer discovery protocols MPLS

Addressing: Address Resolution Protocol (ARP) Neighbor Discovery Protocol HSRP VRRP

Network layer: IPinIP ICMPv6 Mobile IP (MIP) RSVP

Transport layer:

Support applications: DHCP DNS MDNS NTP
Routing protocols: RIP OSPF EIGRP BGP
Security: RADIUS Diameter
Network management: Simple Network Management Protocol (SNMP) syslog IPFIX: IP Flow Information Export Service Location Protocol WPAD ISATAP
End-user applications: Email SMTP IMAP Post Office Protocol (POP) Messaging Voice over IP (VOIP)




Standard encapsulation
Classic request to get root page on example.com, with HTTP encapsulated within TCP, in IP and Ethernet.
From: Tim

Error checks
PPI encapsulation captures the whole 802.11 frame, including Frame Check Sequence. Inside is a DNS request, encapsulated in UDP, IP and LLC. In addition to the 802.11 FCS, UDP provides a checksum over the data, and IP provides a checksum over its header.
From: Wireshark sample captures: HTTP

Link layer


ARP leak
Memory leaking into Ethernet padding
From: http://www.packet-level.com/traces/arp-badpadding.zip
Ethernet II, 802.3 and 802.3 raw frames
From: http://www.packet-level.com/traces/eframes.zip
Wake On LAN
"WakeOnLAN sample packets generated from both ether-wake and a Windows-based utility."
From: http://wiki.wireshark.org/WakeOnLAN
Wake On LAN
From: Tim

IEEE 802.11

Wifi / Wireless LAN
new client joining the network
"802.11 capture of a new client joining the network, authenticating and activating WPA ciphering"
From: http://wiki.wireshark.org/SampleCaptures
Wifi retransmission
From: Frames 743-755 of the above
"Description: 802.11 capture with WPA data encrypted using the password "Induction". "
From: http://wiki.wireshark.org/SampleCaptures
"802.11n capture with PPI encapsulation containing HTTP data." (Works with Wireshark 1.0.8 but not 0.99.5)
From: http://wiki.wireshark.org/SampleCaptures


Various USB devices
"Various USB devices on a number of busses"
From: http://wiki.wireshark.org/SampleCaptures
USB mouse
"Usb packets exchanged while unpluggin and replugging a mouse"
From: http://wiki.wireshark.org/SampleCaptures
USB stick
"Plug in a USB2.0 stick, mount it, list the contents." (capture file cut short?)
From: http://wiki.wireshark.org/SampleCaptures
USB hub and presenter
"Plug in a usb2.0 4-port hub without external powersupply, plugin a logitech presenter into one of the ports, press a button, unplug presenter, unplug hub. Repeat with externally powered hub."
From: http://wiki.wireshark.org/SampleCaptures

Firewire / IEEE 1394

"An ICMP packet encapsulated in Apple's IP-over-1394 (ap1394) protocol" though IP/ICMP content seems to have been censored
From: http://wiki.wireshark.org/SampleCaptures

Powerline / BPL

Intellon Homeplug (INT51X1)
"Request Channel Estimation (RCE) frame."
From: http://wiki.wireshark.org/SampleCaptures
"Request Parameters and Statistics (RPS) frame"
From: http://wiki.wireshark.org/SampleCaptures
"Network Statistics basic (NS) frame."
From: http://wiki.wireshark.org/SampleCaptures


"Two devices join a ZigBee network and authenticate with the trust center. Network is encrypted using network keys and trust center link keys."
From: http://wiki.wireshark.org/SampleCaptures

Asynchronous Transfer Mode (ATM)


From: http://www.pcapr.net/view/nos/2011/3/1/13/ATM_SSCOP.pcap.html

Spanning Tree Protocol


From: http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=stp.pcap
Rapid STP
"Rapid Spanning Tree Protocol BPDUs are received from a Catalyst switch after connecting to a port not configured for PortFast. The port transitions through the blocking and learning states before issuing a topology change notification (packet #30) and transitioning to the forwarding state."
From: http://packetlife.net/captures/protocol/stp/
STP ads
"IEEE 802.1D Spanning Tree Protocol (STP) advertisements sent every two seconds."
From: http://packetlife.net/captures/protocol/stp/
= rapid spanning tree from http://www.pcapr.net/view/bwilkerson/2008/10/3/11/f093d4e0-9803-012b-b2a6-0016cb8cea27.cap.html

Link-layer discovery protocols

IEEE 802.1AB Link Layer Discovery Protocol (LLDP)

Periodic LLDP with CDP
From: http://packetlife.net/captures/protocol/lldp/
From: http://wiki.wireshark.org/SampleCaptures
From an Extreme Networks Summit 300 switch
From: http://wiki.wireshark.org/SampleCaptures
From HP Procurve switch
From: http://wiki.wireshark.org/SampleCaptures

Proprietary discovery protocols

Cisco CDP
From: http://wiki.wireshark.org/SampleCaptures
Cisco CDP from a Catalyst 3560
3 CDP packets, sent once per minute
From: http://packetlife.net/captures/protocol/cdp/
Extreme Networks EDP
From: http://wiki.wireshark.org/SampleCaptures

Misc protocols using link

Configuration Test Protocol (loopback)

802.1Q virtual lans

"Lots of different protocols, all running over 802.1Q virtual lans."
From: http://wiki.wireshark.org/SampleCaptures

GARP VLAN Registration Protocol (GVRP)

From: http://www.pcapr.net/view/jschmidt/2009/1/1/16/binsb7gv1KFfl.bin.html


MPLS-encapsulated IP
"A basic sniff of MPLS-encapsulated IP packets over Ethernet."
From: http://wiki.wireshark.org/SampleCaptures
Double stack of MPLS labels
Packets with a stack of 2 MPLS labels
From: http://www.pcapr.net/view/chetan.shah/2011/6/5/21/mpls-label_stack_double.cap.html
IP EXP bits
"IP packets with EXP bits set."
From: http://wiki.wireshark.org/SampleCaptures
MPLS Traffic Engineering
"Includes RSVP messages with MPLS/TE extensions and OSPF link updates with MPLS LSAs."
From: http://wiki.wireshark.org/SampleCaptures
MPLS traceroute

From: http://www.pcapr.net/view/kowsik/2009/4/5/11/mpls-traceroute.pcap.html
two-level tagging
"An IP packet with two-level tagging."
From: http://wiki.wireshark.org/SampleCaptures
MPLS encapsulation
"Capture taken from the PE1-P1 link. ICMP traffic between CE1 and CE2 is encapsulated outbound with MPLS label 18. Note that returning traffic is not labeled, due to penultimate hop popping (PHP)"
From: http://packetlife.net/captures/category/mpls/
LDP adjacency
"PE1 and P1 multicast LDP hellos to on UDP port 646. They then establish an adjacency on TCP port 646 and exchange labels."
From: http://packetlife.net/captures/category/mpls/
Tag Distribution Protocol
"P2 and PE2 exchange Tag Distribution Protocol hellos and form an adjacency over TCP port 711."
From: http://packetlife.net/captures/protocol/cisco-tdp/


Address Resolution Protocol (ARP)

See also Ethernet padding of ARP leaking data
Standard Operation

From: http://www.packet-level.com/traces/index.htm
Reverse ARP
"A reverse ARP request."
From: http://wiki.wireshark.org/SampleCaptures

Neighbor Discovery Protocol

"Neighbor Discovery Protocol (NDP) uses ICMPv6 to perform duplicate address detection and address resolution. Also includes multicast listener reports."
From: http://packetlife.net/captures/protocol/

Hot Standby Router Protocol (HSRP)

2 routers and .3 are using HSRP and acting as one virtual router with address Both routers advertise themselves through HSRP every second. 92.2 is the active router and advertises itself using the All-HSRP-routers_00 MAC address as its source address and 92.3 is the standby and advertises itself using its Cisco_00:12:41 MAC address. When a host communicates via the router it sends to the All-HSRP-routers_00 MAC address and receives replies from Cisco_18:a4:41 - presumably the true MAC address of the active 92.2 router.
From: Tim

Virtual Router Redundancy Protocol (VRRP)

“The master router (R1) goes offline. After the down interval passes (roughly 3 seconds), R3 takes over as the master router in packet #12. R2 also offers to take over but R3 wins because it has the higher IP address.”
From: http://www.pcapr.net/view/bwilkerson/2008/10/3/11/01aa58e0-9804-012b-b2a6-0016cb8cea27.cap.html

Network layer

See also routing


"Packets 8 and 9 show the overlapping IP fragments in a Teardrop attack."
From: http://wiki.wireshark.org/SampleCaptures
Path MTU discovery
"Tracepath is used to determine the MTU of the path between hosts and .1.2. Packet #6 contains an ICMP fragmentation needed message, indicating the MTU for that hop is 1400 bytes." - description from pcapr
From: http://packetlife.net/captures/path_MTU_discovery.cap


IPv6 fragmentation from Tim


Tunneling IPv6 in IPv4
From: Packetlife: IP-in-IP



Mobile IP (MIP)

MIPv6 binding update
From: http://www.pcapr.net/view/kowsik/2009/5/2/14/binding-update.pcap.html

Resource Reservation Protocol (RSVP)

From: http://www.pcapr.net/view/bwilkerson/2008/10/3/11/9c1b8eb0-9804-012b-b2a6-0016cb8cea27.cap.html
See also MPLS Traffic Engineering

Transport layer

Not particularly interesting unless


Support applications


"A sample of DHCP traffic"
From: http://wiki.wireshark.org/SampleCaptures
"A sample session of a host doing dhcp first and then dyndns."
From: http://wiki.wireshark.org/SampleCaptures
"A sample packet with dhcp authentication information."
From: http://wiki.wireshark.org/SampleCaptures
Standard Boot Sequence
"Standard Boot Sequence"
From: http://www.packet-level.com/traces/index.htm


Various DNS queries and responses
Each query (in an odd-numbered packet) is followed immediately by its response in an even-numbered packet.
packet 1: Standard request for IPv4 address
packet 3: Reverse lookup of name corresponding to IPv4 address. Since address is link-local, name does not exist
packet 5: Reverse lookup of name corresponding to IPv4 address. Name exists this time
packet 7: Standard request for IPv4 address, this time with multiple answers
packet 9: Standard request for IPv4 address, this time name is an alias for another name
packet 11: Server sends no answers since it isn't authoritative and doesn't know answer
packet 13: Know from authoritative server that name does not exist
packet 15: Query causes server failure
DNS retransmission
The primary DNS server (.17) is slow to respond to the client, so after a timeout (about 0.9sec) the client resends the query to a different server (.2) which responds faster. The primary server eventually answers, but by that time the client has stopped waiting for the response, causing an ICMP error in response to the late answer.
From: Tim
Fault Operation
"Fault Operation" (ICMP port unreachable, suggesting server process not running.)
From: http://www.packet-level.com/traces/index.htm
Hotel: DNS problems
"Hotel: DNS problems"
From: http://www.packet-level.com/traces/index.htm
Various DNS lookups
"Various DNS lookups"
From: http://wiki.wireshark.org/SampleCaptures


mDNS traffic from EE&T LAN

From: Tim

Network Time Protocol (NTP)

client at UNSW receives response from Apple server
Since NTP is sent unreliably over UDP, and servers are often congested, few client requests receive responses
From: Tim

Routing protocols

Routing Protocols routing


"Capture perspective from R1's interface." from RIP:
Event RIPv1 RIPv2
Router periodically floods its database RIPv1 RIPv2
"routes are being flooded on the R1-R2 link. R2's connection to goes down, and the route is advertised as unreachable (metric 16)" RIPv1 RIPv2
Tim's description:
This capture shows two routers and updating each other using the distance-vector RIP protocol. has paths to, and Both have paths to has paths to, and In frames 1-6 the routers periodically update each other about the paths that they have; they do not tell each other about paths that they learn from the other, so it seems that split-horizon is being used. In frame 7, advertises a cost of infinity (16) to reach the network, and that is echoed by in frame 8, and reappears in normal periodic updates in frames 9 & 10. This demonstrates poison reverse: routers advertise unreachable routes on the interface over which they were learned.
route exchange
"A basic route exchange between two RIP v1 routers"
From: http://wiki.wireshark.org/SampleCaptures
"RIPng packets (IPv6)"
From: http://wiki.wireshark.org/SampleCaptures


OSPF Link State Advertisements
From: pcapr
Tim's description:
This capture seems (judging by the source addresses of the OSPF messages) to have been made on a link between two routers and Frames 50 and 51 give examples of router link state advertisements. The OSPF header indicates the source of each message, and "data" for each link in the LSA either indicates the subnet mask (for links that connect to stub networks) or the interface on the router making the advertisement that connects to the link (for transit and peer-to-peer links). Frame 50 from router indicates that it is connected to a stub network, to a transit network through its interface, and to two other routers and Whenever a router advertises a PTP link to another router, it also advertises a /30 stub for that link. Frame 51 from router is in the transit network, and it also indicates that it is connected to the router (but strangely, not the router which sent the previous frame).
Simple OSPF initialization
From: http://wiki.wireshark.org/SampleCaptures
Simple OSPF-MD5 Authentication
From: http://wiki.wireshark.org/SampleCaptures


"Two Cisco EIGRP peers forming an adjacency."
From: http://wiki.wireshark.org/SampleCaptures
IPv6 updates
"Cisco EIGRP packets, including IPv6 internal and external route updates"
From: http://wiki.wireshark.org/SampleCaptures


eBGP adjacency
"The external BGP adjacency between routers 1 and 2 is brought online and routes are exchanged. Keepalives are then exchanged every 60 seconds. Note that the IP TTL (normally 1) has been increased to 2 with ebgp-multihop to facilitate communication between the routers' loopback interfaces."
From http://packetlife.net/captures/protocol/bgp
iBGP adjacency
"Routers 3 and 4 form an internal BGP relationship. This is evidenced by the OPEN messages in packets #4 and #5, which show both routers belong to the same AS (65300). Also note that IBGP packets are not subject to a limited TTL as are EBGP packets."
From http://packetlife.net/captures/protocol/bgp
Update with AS set
"Packet #15 includes a BGP update containing both an AS sequence and an AS set in its AS path attribute."
From http://packetlife.net/captures/protocol/bgp
"R1 has been misconfigured to expect R2 to reside in AS 65100. R2 attempts to peer with R1 advertising itself correctly in AS 65200. R1 issues a NOTIFICATION in packet #5 citing a "bad peer AS" error and terminates the TCP connection."
From http://packetlife.net/captures/protocol/bgp
"R1 performs a soft bidirectional reset (clear ip bgp soft) on its adjacency with R2. The ROUTE-REFRESH message is visible in packet #7. Note that the TCP connection remains uninterrupted, and neither router views the reset as disruptive."
From http://packetlife.net/captures/protocol/bgp
"A hard reset (clear ip bgp) is performed on R1 for its adjacency with R2. Packet #7 shows R1 sending a packet with the TCP FIN flag set, indicating the connection is to be torn down. The TCP connection is then reestablished and UPDATEs are retransmitted."
From http://packetlife.net/captures/protocol/bgp
"BGP packets, including AS path attributes."
From: http://wiki.wireshark.org/SampleCaptures


IGMP Standard Operations

From: http://www.packet-level.com/traces/index.htm


These traces focus on accounting and charging
RADIUS Accounting Request and Response
From http://www.pcapr.net/view/bwilkerson/2008/10/3/12/radius_acctnas.pcap.html
GPRS Tunneling Protocol (GTP), RADIUS Accounting-Request and Response, Diameter Device-Watchdog-Request and Answer
From http://www.pcapr.net/view/nos/2011/6/5/5/traces_new.cap.html
Diameter Credit-Control Application, including initial request, update and termination
From http://www.pcapr.net/view/mahiccc/2012/6/2/4/diameter_ccr_initiate_update_terminate.pcap.html
Diameter Capabilities-Exchange-Request and User-Authorization-Request (but no Answer)
From http://www.pcapr.net/view/bwilkerson/2008/10/3/12/diameter_user_authorization.pcap.html

Network management

See also Link-layer discovery protocols

Simple Network Management Protocol (SNMP)


From: Tim
SNMPv1 get requests & responses
"A collection of SNMP GETs and RESPONSEs"
From: http://wiki.wireshark.org/SampleCaptures
SNMPv1 set request and response
Wireshark (at least v1.2.1) incorrectly labels the response a get response
From: http://www.pcapr.net/view/bwilkerson/2008/10/3/12/snmp-set.pcap.html
SNMPv1 trap

From: http://www.pcapr.net/view/bwilkerson/2008/10/3/12/snmptrap.pcap.html
getBulkRequest probing
GetBulkRequest starting with Internet MIB and asking for 2250 repetitions. Doesn't hurt to ask, but this is more likely to be probing for info for an attack rather than legitimate.
From: Tim
"SNMPv2c get requests are issued from a manager to an SNMP agent in order to monitor the bandwidth utilization of an interface."
From: http://packetlife.net/captures/protocol/snmp/
SNMPv2c get-bulk request & response
From: http://www.pcapr.net/view/bwilkerson/2008/10/3/12/snmp-get-bulk.pcap.html
"A series of authenticated and some encrypted SNMPv3 PDUS "
From: http://wiki.wireshark.org/SampleCaptures
report PDU (SNMPv3)

From: http://www.pcapr.net/view/bwilkerson/2008/10/3/12/snmp-v3-discover.pcap.html


ala RFC 3164, i.e. pre RFC 5424
Message suggests this is from a Nokia IPSO firewall (& MAC source address supports that)
From: http://www.pcapr.net/view/mike.kuzman/2009/1/4/14/syslog.pcap.html

IPFIX: IP Flow Information Export

“IPFIX traffic generated by nProbe tool”
From: http://www.pcapr.net/view/george.zhitar/2009/3/4/4/ipfix_from_nprobe.pcap.html
“the default options (which are configurable), these are: UDP dst prt 9995; Version preipfixv9 (other options are ipfix & preipfixv5) Now I must admit I cannot verify the attached capture file, so let me know if it is OK”
From: http://thwack.com/forums/p/14714/61517.aspx

Service Location Protocol (SLP/srvloc)

Host 181.3 tries to discover (other) hosts that provide Novell timesync service, then host 181.1 unsuccessfully tries a couple of times (XID 56637 and 21424) to discover a directory agent before also trying to discover Novell timesync service which host 181.3 responds to, though 181.1 is blocking 181.3 so sends ICMP error back to 181.3 and repeats discovery requests.
From http://www.pcapr.net/view/tyson.key/2010/0/5/20/NetWare-New_Network-1_00004_20100115233110.pcap.html

Web Proxy AutoDiscovery (WPAD)

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)

Microsoft Windows computer tries to discover WPAD and ISATAP servers when booting

End-user applications



Standard Email Receipt

From: http://www.packet-level.com/traces/index.htm

Post Office Protocol (POP)


From: http://www.pcapr.net/view/bahubalip2003/2009/3/3/7/sample_pop3.pcap.html


Capture file seems damaged
"A short IMAP session using Mutt against an MSX server."
From: http://wiki.wireshark.org/SampleCaptures


"MSN Messenger packets"
From: http://wiki.wireshark.org/SampleCaptures

Voice over IP (VOIP)

"A VoIP sample capture of a H323 call (including H225, H245, RTP and RTCP)."
From: http://wiki.wireshark.org/SampleCaptures


Forget-me-not Capture taken from a host on a switched network. Another host .144 seems to be online initially, with the only traffic involving it being broadcast announcements BROWSER/NBNS (every 12min = 720sec during the first 2 hours = 8210 sec) - other unicast traffic is presumably being switched directly to/from it. After 8210sec, it goes quiet (offline?).
Switch forgets: 7.5min later (8662sec) we see UDP traffic from an external source (189.46...) still being sent to it - presumably the switch hasn't seen it transmit so has aged-out its location and is flooding packets for it. .144 also seems to be the target of an SNMP attack. SNMP traffic after 9300sec has been removed for clarity.
Router questions ARP record: We haven't seen any ARP traffic for .144 - presumably the router forwarding the SNMP traffic remembers its MAC address from earlier. 15 minutes later (9270sec) the router starts ARPing for it; 15 minutes = 20min ARP table ageing default - 5min switch learning ageing default.
Server remembers: Later (e.g. 9312sec) we also see TCP traffic being sent to .144 - it looks like a server is trying to retransmit a web object that .144 had requested. The server has been patient - it is now 18 minutes since we (and presumably it) last saw signs of life from .144 (8210sec).
Router widens ARP search: From 9418 to 9603, the router continues ARPing .144 - to help deliver the continuing SNMP requests - not shown. At 9642, the router decides to forget .144's old MAC address and instead broadcast ARP requests for .144. Note how the router doubles the period between ARP retransmissions: 2sec, then 4sec, then 8sec, then around 16sec (often 18), then repeats.