I'm experiencing unexpected packet loss on a 10Gbps Intel NIC (ixgbe driver) even when traffic is only around 10Mbps. The setup is a test environment using tcpdump to capture packets on Ubuntu 22.04 with kernel 6.2.0. Of course, I replaced cable, nic port (I used another port), nic but the result is the same. ### Observations: - Traffic generator sent 46,759 packets. - Only 37,676 packets were captured by tcpdump. - ethtool -S shows rx_dropped: 7 and rx_packets: 37,676. - tcpdump reports: 0 packets dropped by kernel. - NIC driver: ixgbe, firmware 1.808.0 - rx-usecs is set to 20, RX ring set to 8192. - RPS enabled: echo ffff > /sys/class/net/ens4f1/queues/rx-0/rps_cpus - IRQs are spread: all affinities set to 0-31 - NUMA node for NIC is 0, CPUs in node0 are 0-13,28-41. - /proc/softirqs shows NET_RX is active on multiple cores. ### Tried so far: - Reloading ixgbe driver (modprobe -r ixgbe && modprobe ixgbe) - Increasing RX ring buffer (ethtool -G ens4f1 rx 8192) - Disabling ntuple filtering and re-enabling (ethtool -K ens4f1 ntuple on) - Enabling rxhash (ethtool -K ens4f1 rxhash on) - Testing different rx-usecs (20, 50, 100) - Ensured IRQ and RPS distribution ### Questions: 1. Could the NIC drop packets even if rx_dropped is low and no kernel drops are shown? 2. Is there any known ixgbe behavior or firmware bug that could cause packet loss in such low load? 3. How can I confirm whether packet loss is really happening at the NIC or somewhere else in the kernel path? Any suggestions on further debugging or known limitations would be greatly appreciated.

I would like to view TCP requests (syn packets) initiated by my PC/server to other hosts. More specifically, I would like to view the outgoing connection requests. How can I accomplish this? Also, I don't want to see any connection attempts that are coming to my PC/server. The following iptables command works but it's clunky to use as it logs everything while I just want to see everything on the screen: iptables -I OUTPUT 1 -o eth0 -p tcp -m state --state NEW -j LOG

I have been trying to learn tcpdump and I am using this command to attempt to monitor my network: sudo tcpdump -I -i en1 But this gives me a bunch of stuff I don't want, so I used this version to filter the packets: sudo tcpdump -I -i en1 port 80 or 443 And it gives me nothing. I know you can't use your WiFi when using monitor mode, but I still can, so I think thats a sign something is wrong. I tried it with en0, but it couldn't go into monitor mode. What am I doing wrong? I am using a MacBook Pro with OS X 10.9.3, and I would like to be able to do this with tcpdump, or any other utility that's built into OS X.

On ifconfig I can see the number of packets sent/received with the tx/rx values. With that interface on promiscuous mode, if I turn on tcpdump on that interface I should see all packets sent/received on that interface right? Using: tcpdump -XX -e -n -s0 -i (There may be redundancy in the options :p) And yet I don't see all packets sent. Any ideas? **EDIT**: also, I read the ifconfig manual and it reads: _"Ifconfig is used to configure the kernel-resident network interfaces."_ So, ifconfig reads tx/rx at kernel level right? Is there any way to get these readings at driver level? **EDIT2:** also, can the driver be programmed to send the packets to the kernel AND to a running program? **EDIT3:** could I make a program to sniff _ANY_ bytes passing on the interface, regardless of their format? Perhaps tcpdump is not giving me the packets because it cannot perceive their format.

Here is what I'm trying to do (CentOS 7): root@serv02 # /usr/sbin/tcpdump -nn -i eno16780032 -s 0 udp port 53 -w /var/opt/A.pcap -C 100 -W 30 tcpdump: /var/opt/A.pcap00: Permission denied I'm running this as root and the file system is not full. I just don't understand why tcpdump does not create the file. The command worked fine without -C and looked like -C caused tcpdump to drop privileges, but why?

I'm developing a backend server and here is how the architecture of the backend looks like: APP --> Server1 --> Server2 --> Server3 --> MyServer APP sends a HTTP request to the Server1, and all of the servers at backend communicate each other with the method RPC, which is based on the TCP protocol. I'm developing the MyServer and since my job hasn't finished yet, I need to do many tests, but the Server3 is not always available. I don't know what Server1, Server2 and Server3 did and the RPC from Server3 to MyServer is really complicated, it contains many parameters that I don't know. What I need is to capture a request from Server3, copy it's content to a script so that I can run the script to simulate a request. Let me make an example: Server3 will send a RCP to MyServer with the parameters p1, p2, p3. For me, I only care about p3, so I process the p3, generate a new parameter p4, and send p1, p2 and p4 to another server. So I need to simulate a RPC from Server3 so that I can send whenever I need to test the MyServer. **About protocol** Our team used a private framework, it has its own protocol to make a RPC. All I know is that the protocol is based on TCP, instead of HTTP. So what I need is to capture a request from Server3 and replay it whenever I need.

Right now I'm using tcpdump -i -p -s0 -w /tmp/file.cap and then filter the capture in wireshark. How can I take packet capture with tcpdump only on SCCP or GSM_MAP protocols and drop the sctp heartbeat messages? Any other solution will also be good :) OS: RedHat

I'm writing a Wireshark dissector for our CAN bus protocol and I've noticed that tcpdump captures CAN frames twice and its output differs from candump program. For example, when I execute following commands

$ cansend vcan0 123#R
$ cansend vcan0 123#22

tcpdump shows following output

$ tcpdump -i vcan0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vcan0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
00:19:18.372611
    0x0000:  2301 0040 0000 0000 0000 0000 0000 0000  #..@............
00:19:18.374097
    0x0000:  2301 0040 0000 0000 0000 0000 0000 0000  #..@............
00:19:33.605064
    0x0000:  2301 0000 0100 0000 2200 0000 0000 0000  #.......".......
00:19:33.610799
    0x0000:  2301 0000 0100 0000 2200 0000 0000 0000  #.......".......

but candump shows it correctly.

$ candump vcan0
  vcan0  123     remote request
  vcan0  123     22

tcpdump version

$ tcpdump --version
tcpdump version 4.9.2
libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)

I have two questions 1. Is there any solution to this problem or is it solved in a newer version? 2. If no or newer version is required, can I use candump in Wireshark remote capture? I know I can preview candump logs, but I would prefer live inspection using remote capture.

I'm using a fresh minimal Ubuntu server 24.04.1 LTS install. I run these commands as root to set up networking and do some experiments: > If you have seen [this post](https://unix.stackexchange.com/q/787076/203214) , it's the same setup but with the ip address 2.3.4.5 assigned to my_veth2 and the routing table entry 1.2.3.0/24 to make sure data can be sent and received from each network namespace.

# Terminal 1

apt install -y netcat-traditional tcpdump

ip netns add ns1
ip netns add ns2

ip link add my_veth1 type veth peer name my_veth2

ip link set my_veth1 up netns ns1
ip link set my_veth2 up netns ns2

ip -n ns1 address add 1.2.3.4 dev my_veth1
ip -n ns1 route add 2.3.4.0/24 dev my_veth1
ip -n ns2 address add 2.3.4.5 dev my_veth2
ip -n ns2 route add 1.2.3.0/24 dev my_veth2

ip netns exec ns2 nc -l -p 8080

then I open 2 more terminals to run tcpdump in each network namespace:

# Terminal 2
ip netns exec ns1 tcpdump -i my_veth1

# Terminal 3
ip netns exec ns2 tcpdump -i my_veth2

then I open one more last terminal to send data to the netcat server in ns2 from ns1:

# Terminal 4
ip netns exec ns1 nc 2.3.4.5 8080 <<< 'Hello world from network namespace ns1'

Results: * The message sent from Terminal 4 is printed in Terminal 1, as expected. * No packets are being shown in either tcpdump. **WHY?**

How can I filter tcpdump output (normal screen, not -w) to only see lines with flag [P]? Running tcpdump 4.99 on Debian 12

I am unable to capture **unicast** traffic on the br0 (**linux bridge**) interface using the command tcpdump -nni any -vvv. Broadcast traffic, however, is captured as expected. Interestingly, unicast traffic is captured if I open another terminal and run tcpdump -nni br0 -vvv to capture traffic specifically on the br0 interface simultaneously. I've noticed that this behavior is present with tcpdump version *4.9.3* (libpcap version 1.8.1), where the tcpdump -nni any -vvv command does not capture br0 unicast traffic. However, using tcpdump version *4.99.5* (*libpcap version 1.10.5 with TPACKET_V3*) works correctly and captures the unicast traffic on br0. I know that br0 get the all traffic which flow into the linux bridge device, see also Anatomy of a Linux bridge . > In cases where the destination MAC address of the incoming frame is multi- or broadcast, the bridge device is set to receive all traffic, or the address is matches one of the local interfaces, a clone of the frame is also delivered upwards in the local network stack by calling the br_pass_frame_ up function. The function updates the bridge device statistics, and passes the incoming frame up the network stack by calling the device independent netif_receive_skb function I suspect that I'm seeing may be related to the version of tcpdump or its parameters, but I can't confirm this. Could you help explain the reason for this behaviour?

I am facing the following issue when running

between two nodes in the same subnet. This is done as a test whether the network connection between this 2 nodes is reliable or not. We were told to use this approach from a known DB vendor's Support Team. While running the command:

-s 10.1.3.205 -r 10.1.3.210

there are packets randomly not received, and no RTT is reported:

traceroute -s 10.1.3.205 -r 10.1.3.210
traceroute to 10.1.3.210 (10.1.3.210), 30 hops max, 60 byte packets
 1  10.1.3.210 (10.1.3.210)  0.152 ms  0.064 ms *

In opposite, running traceroute with option ICMP:

traceroute -I -s 10.1.3.205 -r 10.1.3.210

is reliable and no missing packets occur. The same issue was discovered on several Linux systems in our environment with different patch levels, different versions of traceroute and no matter whether system is a VM or physical. To simplify and for easier reading of tcpdump, I tried with the following command:

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done

The output is the following:

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; done
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.203 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.071 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.075 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  *
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.142 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.067 ms
traceroute to 10.1.3.210 (10.1.3.210), 1 hops max, 28 byte packets
 1  10.1.3.210  0.054 ms

Every 7th packet gets no response and this is reproducable. Now the Support team finalizes like we would have an issue in our network setup with this packet loss. Running the same loop with a delay of 1 sec. all 10 packets are sent and received:

for i in {1..10}; do traceroute -s 10.1.3.205 -r 10.1.3.210 -n 1 -m 1 -q 1; sleep 1; done

I am a little bit in doubt if this way of testing network reliability is correct or not, since usually traceroute is being used for monitoring of network path over routed connections. I tried a network connection test over several hours with

from SAP, where no lost connections where discovered. So is there anything obvious I have missed and is using

this way a feasible way to test network reliabilty?

I'm trying to capture raw/binary Ethernet traffic from my interface, so I can parse it using C. I don't want to parse any PCAP headers. I would prefer without the preamble and end bytes, but it's okay if it's easier to include. Unfortunately when I capture using Wireshark it always adds a PCAP header. Consequently I tried Tcpdump: sudo tcpdump -w - -U | tee ~/test.raw. However, I open the file in Wireshark, View, Reload as File Format/Capture and it also added a pcap header (see below). How can I record the raw frame + packets without any PCAP information?

I would like to capture traffic on Linux virtual interfaces, for debugging purposes. I have been experimenting with veth, tun and dummy interface types; on all three, I am having trouble getting tcpdump to show anything. Here is how I set up the dummy interface: ip link add dummy10 type dummy ip addr add 99.99.99.1 dev dummy10 ip link set dummy10 up In one terminal, watch it with tcpdump: tcpdump -i dummy10 In a second, listen on it with nc: nc -l 99.99.99.1 2048 In a third, make an HTTP request with curl: curl http://99.99.99.1:2048/ Although in terminal 2 we can see the data from the curl request, nothing shows up from tcpdump. A Tun/Tap tutorial clarifies some situations where the kernel may not actually send any packets when one is operating on a local interface: > Looking at the output of tshark, we see...nothing. There is no traffic going through the interface. This is correct: since we're pinging the interface's IP address, the operating system correctly decides that no packet needs to be sent "on the wire", and the kernel itself is replying to these pings. If you think about it, it's exactly what would happen if you pinged another interface's IP address (for example eth0): no packets would be sent out. This might sound obvious, but could be a source of confusion at first (it was for me). However, it is hard to see how this could apply to TCP data packets. Maybe tcpdump should be bound to the interface a different way?

I am trying to capture mysql traffic using tcpdump and converting it to text using strings command, but while capturing mysql traffic, I am getting some extra character at the end of each character. I am unable to figure out the reason. e.g. CREATE TABLE foo1.foo (id INTEGER, name VARCHAR(20))H> As you can see, there is H> at the end of query. Can someone help me in solving this. **Edit:** I am running the following command to capture the traffic. $ sudo tcpdump -i any -s 0 -l -w - dst port 3306 | stdbuf -i0 -o0 -e0 strings -12

I want to trace the networking activity of a command, I tried tcpdump and strace without success. For an example, If I am installing a package or using any command that tries to reach some site, I want to view that networking activity (the site it tries to reach). I guess we can do this by using tcpdump. I tried but it is tracking all the networking activity of my system. Let's say if I run multiple networking related commmands and I want to track only particular command networking activity, that time it is difficult to find out the exact solution. Is there a way to do that? **UPDATE:** I don't want to track everything that goes on my network interface. I just want to track the command (for an example #yum install -y vim) networking activity. Such as the site it tries to reach.

I run tcpdump with a filter like: not ( (host 1.165.155.169 and port 4444) or (host 1.168.68.116 and port 4444) or (host 1.173.192.253 and port 4444) or (host 1.174.97.43 and port 4444) : or (host 161.138.104.1 and port 58339) ) My problem is that tcpdump takes O(n²) time when starting, and I have several 100s of lines. When it is started, it works fine. It seems it is only the initialization that is O(n²) - not the normal processing. Is there a way I can tell tcpdump to optimize initialization to O(n) or at least O(n log n)? I have a table of . **EDIT** Thanks for the ideas. So far all of them give O(n²). There is no reason to wait for me to test your idea. Here is a script to test with: #!/bin/bash # Make some network noise (sudo nice nice ping -f localhost >/dev/null) & noisepid=$! filter() { # $1 = How many entries? perl -e ' $pre = "not ("; $post = ")"; $join = " and "; sub hostport { $host = sprintf "%d.%d.%d.%d", rand()*255,rand()*255,rand()*255,rand()*255; $port = sprintf "%d", rand()*65535; return "(host $host and port $port)"; } print $pre, join($join,map { hostport() } 1..shift), $post; ' $1 } export -f filter seq 400 | parallel --joblog my.log 'sudo tcpdump -ni any "filter {}"|read a' kill -9 $noisepid # field - https://codeberg.org/tange/tangetools/src/branch/master/field # plotpipe - https://codeberg.org/tange/tangetools/src/branch/master/plotpipe field 14,4 < my.log | sort -n | plotpipe tcpdump -F file is faster, but still O(n²). EDIT2: Graphs re-done on other server (i.e. the numbers cannot be compared with previous graph) with tcpdump and tcpdump -O -O clearly makes it worse.

This is the situation: I have two VM (virtual machines) via kvm-qemu connected via virtual-serial (a socket). I created the two vm's with this serial configuration: serial1 (slackware, uses port1 which is ttyS1 or com2) serial2 (unixware use port 0, which is ttyS0 or COM1) The serial works ssh unixware2 cu Slackware1 Connected slackware1 login: I want to sniff the traffic! Searching on net i found this I did that... sudo socat TCP-LISTEN:6004,reuseaddr,fork UNIX-CONNECT:/tmp/ppp.sock and sudo tcpdump -i any -f 'tcp port 6004' -vv -xX tcpdump: data link type LINUX_SLL2 tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel as you can see 0 packet is captured. I've also tried -i lo but no success. Of course I have made some operations (using uux, cu, etc..).

Digging into tcpdump implementation, I can see that it actually loads the libpcap.so dynamic library in userspace. However, by use of strace, I can't see any occurrence of calls to any function exported by libpcap. Is the above an expected behaviour of tcpdump? Thank you. root@eve-ng02:~# tcpdump --help tcpdump version 4.9.2 libpcap version 1.7.4 OpenSSL 1.0.2g 1 Mar 2016 Edit: from received comments I tried with ltrace but it seems no call to dynamic library is done as well. root@eve-ng02:~# ltrace tcpdump -i lo tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes ^C--- SIGINT (Interrupt) --- 0 packets captured 126 packets received by filter 98 packets dropped by kernel +++ exited (status 0) +++ root@eve-ng02:~#

On my Red Hat Enterprise Linux Server release 6.5 when saving a tcpdump capture to a file with the -w option, the resulting file is empty: [root@plop ~]# tcpdump -n -w tcpdump.cap listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes ^C217 packets captured 217 packets received by filter 0 packets dropped by kernel [root@plop ~]# cat tcpdump.cap [root@plop ~]# ll tcpdump.cap -rw-r-----. 1 root root 0 Aug 25 14:13 tcpdump.cap [root@plop ~]# I also tried to redirect the output of the command with > and &>, but I always get an empty file... What could be the reason for this? NB: - I can see a correct output in the terminal (many packets) when not redirecting to a file - I did the same with thsark and it worked as expected (the output file was correct) - The verison of tcpdump is tcpdump version 4.1-PRE-CVS_2012_02_01 - The version of libpcap is libpcap version 1.4.0 - I tried with -U option, it didn't fix the problem.