Packet Captures

Sort by new | name | popular

Viewing 1 - 29 of 29

  • 1

connection termination.cap (316 bytes)

Packets: 4 Duration: n/a Downloads: 3621

This is a connection termination packet in which both the server and client sends fin & ack to each other.
For details of how connection is been teared down by both client and server see the link below.
http://www.firewall.cx/networking-topics/protocols/tcp/136-tcp-flag-options.html

  • Categories: None
  • Protocols: IP, TCP

packet-c.cap (675.0 KB)

Packets: 926 Duration: 13s Downloads: 5240

This is a packet capture from a SonicWall. We were troubleshooting DHCP packet flows. The SonicWall saw the DHCP Discover and Sent an Offer. We never saw the DHCP acknowledgement. In the adjacent core stacked switching we were running "debug ip dhcp server packets" we only saw discover packets from IP phones up to the SonicWall. For some reason the SonicWall could not let any other DHCP packets through or out of it INSIDE (LAN) interface. Even if we put an ANY-ANY ALC for that interface. We ended up having to replace the SonicWall and upload the configuration from the old SonicWall to the new one.

-Slaingod

OCSP-Not_Implemted.cap (1.1 KB)

Packets: 10 Duration: n/a Downloads: 4841

OCSP-Not_Implemted

OCSP-Revoked.cap (1.8 KB)

Packets: 10 Duration: n/a Downloads: 3762

OCSP (Comodo - FAKE crt Addons-mozilla-org)

OCSP-Good.cap (3.5 KB)

Packets: 14 Duration: 1s Downloads: 4476

OCSP_Good (CRL HTTPS CA Verisign)

cm4116_telnet.cap (9.4 KB)

Packets: 113 Duration: 14s Downloads: 6383

Short Telnet session with an Opengear CM4116 used to demonstrate the urgent flag and pointer

HTTP.cap (24.9 KB)

Packets: 40 Duration: n/a Downloads: 10477

Simple HTTP transfer of a PNG image using wget

iphttps.cap (12.4 KB)

Packets: 83 Duration: 38s Downloads: 7144

IP-HTTPS capture. This is Microsoft's IPv6 inside HTTPS tunneling for DirectAccess.

TACACS+_encrypted.cap (2.8 KB)

Packets: 34 Duration: 7s Downloads: 6085

TACACS+ authentication and authorization requests as made by a Cisco IOS router upon a user logging in via Telnet.

BGP_MP_NLRI.cap (2.9 KB)

Packets: 24 Duration: 60s Downloads: 8705

IPv6 routes are carried as a separate address family inside MP_REACH_NLRI attributes.

TCP_SACK.cap (27.5 KB)

Packets: 39 Duration: n/a Downloads: 15270

A TCP SACK option is included in packets #31, #33, #35, and #37. The missing segment is retransmitted in packet #38.

4-byte_AS_numbers_Mixed_Scenario.cap (414 bytes)

Packets: 4 Duration: 60s Downloads: 5332

Router "B" (AS 2) at 172.16.3.2 does not support 4-byte AS numbers, while router "A" (AS 10.1 / 655361) at 172.16.3.1 does.

Router "A" receives an UPDATE for the 40.0.0.0/8 subnet from an external router ("D") in the AS 40.1 / 2621441 (not shown), and it forwards it to "B" (pkt n. 2): AS_PATH contains "23456 23456" (the first stands for AS 10.1, the second for the originating AS 40.1), but NEW_AS_PATH contains the real 4-byte AS numbers.

At pkt n. 3 "B" receives the same subnet directly from "D" and sends it to "A", including the original NEW_AS_PATH attribute previously appended by "D".

4-byte_AS_numbers_Full_Support.cap (1.2 KB)

Packets: 9 Duration: 56s Downloads: 4939

Router at 172.16.1.2 (hostname "D", AS 40.1 / 2621441) clears a previous established peering with 172.16.1.1 (hostname "A", AS 10.1 / 655361); They both support 32-bit ASN.

While opening the new session, they negotiate the "Four-octet AS Number Capability" (pkts n. 2 and 3).

Then, both "A" and "D" send some UPDATEs containing 4-octect encoded AS_PATH attributes (pkts n. 6 and 9). Please note: WireShark may show wrong paths unless you force 4-byte encoding in the Preferences / Protocols / BGP options.

LDP_Ethernet_FrameRelay.pcap.cap (2.1 KB)

Packets: 14 Duration: 7s Downloads: 5226

LDP with pseudowire FEC elements (Ethernet and Frame-Relay DLCI-to-DLCI)

BGP_MD5.cap (1.7 KB)

Packets: 16 Duration: 61s Downloads: 6003

An EBGP with TCP MD5 authentication enabled

BGP_redist.cap (378 bytes)

Packets: 2 Duration: n/a Downloads: 5857

The OSPF metric is preserved and propagated within the MPLS cloud by the MP-BGP MED attribute.

EoMPLS.cap (7.0 KB)

Packets: 56 Duration: 32s Downloads: 5625

Routers at 1.1.2.1 and 1.1.2.2 are PEs in a MPLS cloud. LDP starts at packet 8 and they build up a pseudo-wire VC (last FEC in packets 11 and 13). At packet 15 we already have STP running between CE1 and CE2 (two routers with ESW), encapsulated in 2 MPLS headers. All the ethernet stuff follows: CDP, ARP, ICMP between two hosts on the same subnet.

telnet.cap (9.4 KB)

Packets: 74 Duration: 10s Downloads: 5229

Telnetting from one router to another. Note that all communication is visible in clear text.

TDP.cap (2.8 KB)

Packets: 33 Duration: 47s Downloads: 3299

P2 and PE2 exchange Tag Distribution Protocol hellos and form an adjacency over TCP port 711.

SSHv2.cap (11.4 KB)

Packets: 90 Duration: 7s Downloads: 4677

An SSH version 2 session between two routers. All communication is securely encrypted.

PPP_TCP_compression.cap (1.5 KB)

Packets: 43 Duration: 3s Downloads: 3154

A telnet session is established to 191.1.13.3 across a PPP link performing TCP header compression. The user at 191.1.13.1 logs in with the password "cisco" and terminates the connection.

MSDP.cap (4.1 KB)

Packets: 35 Duration: 391s Downloads: 2959

R2 and R3 become MSDP peers and exchange keepalives. A multicast source 172.16.40.10 begins sending traffic to group 239.123.123.123, and R2 begins sending periodic source active messages to R3. Capture perspective is the R2-R3 link.

LDP_adjacency.cap (5.7 KB)

Packets: 61 Duration: 108s Downloads: 4094

PE1 and P1 multicast LDP hellos to 224.0.0.2 on UDP port 646. They then establish an adjacency on TCP port 646 and exchange labels.

IBGP_adjacency.cap (2.3 KB)

Packets: 17 Duration: 63s Downloads: 3417

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.

EBGP_adjacency.cap (2.7 KB)

Packets: 24 Duration: 182s Downloads: 3439

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.

BGP_soft_reset.cap (2.0 KB)

Packets: 17 Duration: 180s Downloads: 3226

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.

BGP_notification.cap (764 bytes)

Packets: 9 Duration: n/a Downloads: 3131

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.

BGP_hard_reset.cap (3.2 KB)

Packets: 32 Duration: 208s Downloads: 3066

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.

BGP_AS_set.cap (1.6 KB)

Packets: 18 Duration: 1s Downloads: 3567

Packet #15 includes a BGP update containing both an AS sequence and an AS set in its AS path attribute.

Viewing 1 - 29 of 29

  • 1