Hot answers tagged

22

From the tcpdump's manual: packets ``dropped by kernel'' (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0). A bit of explanation: The tcpdump captures raw packets ...


20

Tcpdump has the option -B to set the capture buffer size. The value is then passed to libpcap (library used by tcpdump to do the actual packet capturing) via pcap_set_buffer_size() function. Tcpdump manpage does not specify in what units the buffer size is specified with -B, but from the source it seems that it is KiB. manual page of pcap_set_buffer_size() ...


17

Straight out of man tcpdump -l Make stdout line buffered. Useful if you want to see the data while capturing it. E.g.,``tcpdump -l | tee dat'' or ``tcpdump -l > dat & tail -f dat''.


11

Yes. By putting network interfaces into promiscuous mode, tcpdump is able to see exactly what is going out (and in) the network interface. tcpdump operates at layer2 +. it can be used to look at Ethernet, FDDI, PPP & SLIP, Token Ring, and any other protocol supported by libpcap, which does all of tcpdump's heavy lifting. Have a look at the ...


11

https://facebook.com redirects to https://www.facebook.com which has a different IP Address than facebook.com. There is also ssl.facebook.com but I am not sure what it is used for: $ host facebook.com facebook.com has address 69.171.229.11 facebook.com has address 69.171.224.37 facebook.com has address 66.220.158.11 facebook.com has address 66.220.149.11 ...


11

One more thing to consider/try is that tcpdump may be spending a lot of time doing DNS queries to resolve IPs to domain names. If you don't need those, try throwing in the -n (no lookups) flag. e.g.: tcpdump -n port 80


8

The original DHCP specification (RFC 2131 and 2132) defines an option (33) that allows the administrator of the DHCP service to issue static routes to the client if needed. Unfortunately, that original design is flawed these days as it assumes classful network addresses, which is rarely used. The rfc3442-classless-static-routes option allows you to use ...


7

You can parse the second part of that filter thusly not ( (src and dest) net localnet ) It's shorthand for not src net localnet and not dest net localnet


7

Use Wireshark: tshark -f "udp port 53" -Y "dns.qry.type == A and dns.flags.response == 0"


7

According to man tcpdump: packets dropped by kernel (this is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the OS on which tcpdump is running, if the OS reports that information to applications; if not, it will be reported as 0). The kernel puts captured packets in a fixed-size capture ...


6

The reason you're not seeing them is because you're on a switched network. Your network switch only forwards packets to interfaces to which they are destined. This is determined by the link-layer address listed in the packet. Your switch knows that computers A, B & C are on ports 1, 2 & 3 respectively. When a packet is received from computer A on ...


6

That's probably because a switch only sends traffic down a port if it believes the destination MAC address is attached to that port. On a managed switch, you'd set up monitor mode. On an unmanaged switch, you're left with a couple of options: ARP spoofing, to trick the rest of the network about which MAC address corresponds to the target IP address. You ...


6

The traffic is going over the lo interface. When an IP is added to a box, a route for that address is added to the 'local' table. All the routes in this table route traffic over the loopback interface. You can view the contents of the 'local' table with the following: ip route show table local Which on my system looks like this: local 10.230.134.38 dev ...


5

If you don't have wireshark installed then tcpdumpdns=/tmp/tcpdumps tcpdump -lvi any "udp port 53" | tee $tcpdumpdns should work for you. As you wanted to limit the output to the second to last value then I would parse your log file with: grep -E 'A\?' $tcpdumpdns |sed -e 's/^.*A? //' -e 's/ .*//'|sort -u If you want it live then: tcpdump -lvi any "...


5

0x0030: 061c 0dd8 4745 5420 2f20 4854 5450 2f31 stands for in the line 0x0030: 061c 0dd8 4745 5420 2f20 4854 5450 2f31 This is a hexadecimal representation of data in the packet starting from byte number 0x0030 or 48. 06 is byte 48, 1c is byte 49 and so on. ....GET./.HTTP/1 is a text representation of the same payload string as above.


5

No, I don't think so, from the manpage: -w Write the raw packets to file rather than parsing and printing them out. They can later be printed with the -r option. Stan‐ dard output is used if file is ``-''. -- note "raw packets" -- -v When parsing and printing, produce (slightly more) verbose out‐ put. [.....


5

Unix signal delivery is asynchronous. When the kill system call returns, the signal has been delivered to the process, but the process may not have reacted to it yet. You were lucky with the scheduler under 11.04. If the killed process has a handler for the signal, it can spend an arbitrarily long time before dying, or choose not to die as a result of the ...


5

I quite like tcpdump for recording network connections. You actually can use it for what you want to achieve. Instead of using the READLINE endpoint in your socat connection, make it listen to some port. remote server with ssl ^ | (ssl-encrypted) socat | (not ssl-encrypted) v local port <-- run tcpdump here ^ ...


4

The saved portion of each captured packet is defined by the snaplen option. In some distributions, the default snaplen is set to around 68 bytes. The packets are then truncated to 68 bytes, hiding some of the payload. You can save the complete packets by setting the snaplen to 0 (i.e. maximum) as follows: tcpdump -s0 -w test.pcap -i eth0


4

You seem to want the count instead of the 'Start' output. Display count instead: tcpdump -i any -s 65535 host 192.168.1.110 and port 1645 or port 1813 -v -X | awk '/Start/ {c++;print c} {}' Display count and line: tcpdump -i any -s 65535 host 192.168.1.110 and port 1645 or port 1813 -v -X | awk '/Start/ {c++; print c, $0} {}' Display count on the ...


4

I hope this sheds some light on the issue. From the manpage: When tcpdump finishes capturing packets, it will report counts of: packets captured (this is the number of packets that tcpdump has received and processed); packets received by filter (the meaning of this depends on the OS on which you're running tcpdump, and possibly on the way the ...


4

portrange isn't there in OpenBSD's pcap-filter, but you can fake it. tcpdump -i em0 tcp[2:2] > 79 and tcp[2:2] < 85 You can address parts of the packets and compare against them. First number is offset in the packet (starting at zero) and the second number is how many bytes to use. So the above example matches any tcp packet with a destination ...


4

The tee command writes data to the output file as it receives it, but scp copies the file immediately and only copies it once. Since every command in the pipeline runs simultaneously (or nearly so), you only get a few (or no) packets output to the capture.txt file before the file gets copied by scp. There are a couple ways to do what you seem to want to do. ...


4

For this use case I would suggest capturing only the packets attempting to initiate connections rather than all traffic. That would be anything with only the SYN flag set. tcpdump -ni ${INTERFACE} -w ~/synconnections.pcap tcp[13] == 2 and src host ${MYIP} I cribbed this mostly from the tcpdump man page. The section labelled "Capturing TCP packets with ...


4

That's typically what the -v and -x options of socat are for. -v dumps the data to stderr with some transformation like the CR character becomes \r so you can see it. -x does a hex dump (not very useful though as there's no timestamp or indication of what direction the dumped traffic is flowing in). With -v and -x combined, you get a hd type of dump with ...


4

Filter 'ip6 and icmp6' is all that works for me. According to the manpage, tcpdump doesn't support upper-layer filters on icmpv6; at least with my version. tcpdump version 4.5.1 libpcap version 1.5.3


4

tcpdump -i eth0 -n 'tcp port 5000 and (tcp[tcpflags] & tcp-ack == 0)' should do what you want. It does bitwise and between TCP flags and ACK-only bitmask, so if there's no ACK, the result should equal to zero.


4

You could copy (or stream) the pcap file to your desktop and use the Wireshark GUI for packet analysis. Besides the GUI, there is also the tshark command (included with Wireshark). Given a stream number, you can get its requests and responses combined in a single output with: $ tshark -q -r http.pcapng -z follow,tcp,ascii,1 =================================...


4

When tcpdump "drops" packets, is because it has not enough buffer space to keep up with the packets arriving from the network. The difference between packets captured and received can be due to implementations of the OS or tcpdump, or more commonly due to aborting the process with ^C. Setting the buffer size per packet with "s0" has the consequence of ...


4

You indicated you are connecting via localhost. You will probably need to specify the interface with -i lo (or lo0 on a Mac), so use: sudo tcpdump -i lo -vv -A port ftp or on a Mac: sudo tcpdump -i lo0 -vv -A port ftp The you should see the traffic. The reason: -i Listen on interface. If unspecified, tcpdump searches the system interface list ...



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