Hot answers tagged

31

wireshark - powerfull sniffer which can decode lots of protocols, lots of filters. tshark - command line version of wireshark dumpcap (part of wireshark) - can only capture traffic and can be used by wireshark / tshark tcpdump - limited protocol decoding but available on most *NIX platforms ettercap - used for injecting traffic not sniffing All tools use ...


21

ARP is used by a host on a LAN to resolve a layer-3 address to a layer-2 address so that a frame can be built for the LAN. A router is just another host on a LAN, and it will need to resolve layer-3 addresses to layer-2 addresses, the same way a PC on a LAN does.


10

Here you go! 1. Enter RTP in the display filter in Wireshark when the capture is open. 2. Now select an RTP packet in any stream and click on the menu option Telephony. 3. Go to RTP>Stream Analysis and click on Save Payload button. 4. Change the format to .au and choose a name (lets say test.au) and location for your file. 5. Play it using your favorite ...


7

If you have captured the packets from a single point in the network, then the answer is no. You can tell which hosts are on your network, but there is no topology information that would tell you the route from A to B. If you have some prior knowledge of the addressing scheme, you might be able to infer subnets, but even that is doubtful. Switches and ...


5

You wouldn't be looking for ARP entries with IPv6, since ARP doesn't exist with IPv6. You would be looking for IPv6 ICMP Neighbor Discovery cache. IPv6 MLD messages are used similarly to IPv4's IGMP for Multicast group membership management and also with Neighbor Discovery. If all these are coming from the same source MAC address then I'd start by ...


5

You appear to have a VMware guest running Drobo Dashboard, and it's looking for a Drobo NAS for an iSCSI volume called iqn.1991-05.com.microsoft:desktop002.corp.virtuaprise.com. Port 5002 in this case is just a random port chosen by Drobo for this session. The global broadcast MAC address is just your switch flooding the frame to all ports because the Drobo'...


5

My thoughts on this are that firstly if you capture the traffic in one place (if you are able to, if you have one capture machine/device joint to both mcast groups) you don't have the complexity of having to replay two different captures files in time with each other. Secondly you can edit packet captures so that when you "play" them back the packets are ...


5

show lacp interfaces <aeX> displays detailed state information for each member-link in a LAG. For example: user@router> show lacp interfaces ae0 extensive LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active ge-0/0/1 Partner No No ...


4

I've done this sort of thing before using tcpreplay and mergecap (one of the tools that is distributed with Wireshark). The first step is to use tcprewrite (part of tcpreplay) to edit the destination IPs of foo.pcap to be first address you are looking to send as, and bar.pcap to be the second. Then use mergecap to merge the packets chronologically so you get ...


4

This is generally the case because they want to simplify the UI, specifically avoiding options that many users don't really understand or can cause them problems. The 802.11 feature that leads to the SSID being part of the probe request is the ability to provide a non-broadcast SSID (i.e. hidden SSID). For a client to connect to an SSID that is non-...


4

You can use not ether host 01:23:45:67:89:ab. To filter only source or destination address use not ether src or not ether dst. Check http://www.tcpdump.org/manpages/pcap-filter.7.html


4

You stumbled into the correct filter. If you dig into enough, you'll find the vlan directive changes the packet matching offsets from that point forward in the filter. So you need to have all your non-tagged matches before any tagged matches. (you can tell tcpdump to dump the BPF "program" based on your filter expression and see the effect vlan has.)


4

Ping doesn't send user messages. It generates an ICMP Echo Request that the destination is supposed to answer with an ICMP Echo Reply. Echo requests use a dummy payload data encapsulated within the packet. -p allows you to specify hte content of that payload with some ping versions. -p 12345 fills the payload with 0x012345 bytes repetitively for the ...


4

Wireshark is a graphical application. tshark is that application without the GUI. (i.e. command line.) dumpcap is a further refinement removing the capture logic; it's purpose is to dump a previously recorded capture, possibly filtering it into a new capture file. All three applications can write to a file. The GUI can actually select which packets one wants ...


3

You don't see the ethernet header because you are not capturing traffic on an Ethernet interface. You are using the Linux cooked-mode capture. As per this answer on StackOverflow, which itself refers to The Wireshark Wiki this mode doesn't provide the link-layer header. From the above Wiki page: When capturing from the "any" device, or from one of those ...


3

Hi think you should have a look to https://scapy.net/, with not too much programming you can achieve the task of extract the packets and parsing as json, cvs or whatever.


3

As a workaround, it looks like you can manually copy the capture via CLI to any of the normal destinations: https://www.cisco.com/c/en/us/td/docs/security/asa/asa82/command/reference/cmd_ref/c4.html#wp2144072 This means you should also be able to SCP it off the ASA, if you can't push it to HTTP/FTP/TFTP via the copy command. Here's a good post on using SCP ...


3

Wireshark's capturing engine pcap is designed to capture everything received on an interface. In addition to broadcasts and subscribed multicasts, this includes all link-layer protocols that the upstream switch might be sending, like STP and LLDP. You can deactivate the link-layer protocols on the switch (with the usual caveats) but unless you put up a ...


3

When you think about it, creating a circular buffer within an on-disk file is pretty complex, and not suited at all to typical disk I/O. The only way to make it even marginally feasible is to find a way to write fixed-length entries to the file, which doesn't sound like it would be a good match for a packet trace. As suggested above, I would instead use the ...


2

What do you mean by "debug an interface"? Wireshark & Co. will not help you troubleshoot an Interface problem, but will help you troubleshoot connection/traffic/protocol/payload problem. If you want to troubleshoot that, the best way is to have a PC not involved in the traffic you want to troubleshoot connected to the same Cisco switch and span the ...


2

When the server's MSS is less than 1452, the router should not touch the MSS. The client will see the correct value sent by the server. tcp.len and data.len will match if Wireshark does not interpret the data in the TCP stream. If wireshark can make sense of the data, it can update data.len. They don't have to match. For example, in the case of HTTP, data....


2

If you are using a switch, i guess the only passive option to sniff the traffic for/from that machine is configuring port mirroring(on a capable switch) on the interface connected to that device. There is another way, an ACTIVE scenario called MITM, man in the middle, where you need to spoof the device identity for the switch point of wiew, receiving and ...


2

The pcap-ng format just describes the container format which encapsulates the captured packets. It does not describe the content of the captured packet. Thus if you have captured an IP packet you need to refer to the specification of IP to get the source and destination IP address. And if the captured data also include the ethernet frame you have to remove ...


2

You need to filter for Ethertype 0x8809 frames (for Slow Protocols) with subtype 0x01 (for LACP). You need to run the capture on the physical interfaces, ie. xe. The aggregated, logical ae link doesn't carry those LACPDUs any more - they are consumed by the aggregation layer. See IEEE 802.1AX Clause 6.2.1: Note that problems with the DWDM scheme should show ...


1

The attacker attempts to cause a buffer overflow, where the excessively long password is supposed to overflow out of the password buffer into adjacent memory where it's possibly executed as machine code, overwrites essential data, or is used as a stack return address.


1

for 1 & 2, well, you've got the wrong application for such a job. You can always capture packets with Wireshark. It hooks to an active interface and gives you insight about packets in transit. But the tasks you want to do are more of signal analysis, rather than packet capture. That needs a WiFi-Analyzer. Search for suitable apps for you platform or Try ...


1

You may be better off with something like airodump-ng specifying a channel and optionally a bssid airodump-ng -w file.pcap --channel 6 --bssid 00:11:22:33:44 wlan0


1

A TCP socket is uniquely identified by the four values (remote IP, local IP, remote port, local port). Right, so use a tool like wireshark to identify the culprit! Best of luck!


1

All the packets in your capture are SYN packets. It is the first step of the process of establishing a TCP connection. It seems one one device try to establish a connection with a server, and the server doesn't respond, and the device keep trying. Why the server doesn't respond, we cannot say, it can be a firewall rule or the service on the server that ...


1

Trying dir seems to have solved your problem, showing you the real file name.


Only top voted, non community-wiki answers of a minimum length are eligible