Hot answers tagged

52

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 ...


29

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


20

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 ...


19

netstat for simplicity Using netstat and grepping on the PID or process name: # netstat -np --inet | grep "thunderbird" tcp 0 0 192.168.134.142:45348 192.168.138.30:143 ESTABLISHED 16875/thunderbird tcp 0 0 192.168.134.142:58470 192.168.138.30:443 ESTABLISHED 16875/thunderbird And you could use watch for ...


13

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 "udp ...


12

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 ...


12

Try: tcpdump -i eth0 icmp which will list ping traffic on interface eth0.


12

This is a server class machine with IPMI. The "ghost" NTP server that is causing the issue is running on the BMC processor on the system and not the main CPU.


11

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 ...


9

TL;DR - Pick one: sudo ip addr add 233.54.12.234/32 dev eth1 autojoin socat STDIO UDP4-RECV:22001,ip-add-membership=233.54.12.234:eth1 > /dev/null At first I was going to say "just use ip maddress add and be done with it". The problem is ip maddress only affects link layer multicast addresses not protocol multicast addresses (man 8 ip-maddress)....


9

tail -c +1 -f /Path/to/syscontection.pcap | tcpdump -l -r -


9

You need ICMP type 3 "destination unreachable" packets to provide healthy IP connections. The easiest way to generate ICMP packets type 3 for testing is by using the nping program. The nping program is part of the nmap package, and as such there is a need to have it installed. For it you have to do: sudo apt install nmap After having it installed, to ...


9

The kernel knows "it is already there" and therefore "optimizes" the sending of the ICMP-packets. Thats why you see them on the loopback-interface. Someone else may be able the fill in more details. Nevertheless: I had a similar problem some ages ago and I was able the solve them by creating a new network-namespace with unshare like unshare -n /bin/bash. ...


8

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 ...


8

The guidance on the Wireshark documentation suggests capturing the entire contents of the packet using this command: $ tcpdump -i <interface> -s 65535 -w <some-file> Looking at the man page for tcpdump the guidance there suggests that -s0 should be equivalent: -s Snarf snaplen bytes of data from each packet rather than the default of ...


8

As it has already been said, your IPMI BMC is (probably) the problem. If you cannot get to the web interface or ssh interface of the IPMI interface, you can try to get access using IPMI Tool on your Debian installation: apt install ipmitool Once installed, you can pass commands to the BMC like this (if it is on port 1): ipmitool lan set 1 ipaddr 192.168.1....


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 the option -U in combination with -w so that tcpdump writes packets immediately.


7

You are able to just see the header and not packet contents because you piped the output to grep. So it is just getting the lines in which the IP address is present. -A option to tcpdump gives the packet contents as well.


7

The TS value is a TCP timestamp; it helps determine the order that packets were sent -- see https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure It does not strictly distinguish TCP segments; that is the job of the sequence number which is after the seq.


7

sysdig allows you to monitor all the activity of the kernel or of several commands running in your system in a go, including and not restricted to network activity. As the output can be large, you have to build filters, the default page for the most basic filters is quite comprehensible. It also has the advantage it is not used as an application wrapper as ...


7

I'd create a new network namespace, bridge it over to the real network, and then monitor the bridge with tcpdump.


6

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 ^ ...


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

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.


6

The NFLOG target can be used for this purpose. Here is a very basic example: # Drop traffic by default iptables -P INPUT DROP # add your whitelists here # iptables -A INPUT ... # Pass the packets to NFLOG (just like LOG, but instead of syslog, # it uses netlink). You can add extra filters such as '-p tcp' as usual iptables -A INPUT -j NFLOG # packets that ...


6

To monitor traffic on both directions between host_a and host_b you can use: # tcpdump -nli eth6 host host_a and host_b


6

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 for ...


6

I would use sudo tcpdump -i eth0 -s 0 -w tcpdump.pcap host hostA and udp to up the length to "a lot", write the data to a file and use host rather than src to capture the data in both directions. Essentially you are missing the word and between src and udp.


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.


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