I am trying to understand why when using tcpdump on the loopback interface, only half of the packets received by the filter are captured.
But when I run the exact same traffic and do tcpdump on the eth0 interface all the traffic is captured.
In both cases I am targeting specific ports with the traffic and for the tcpdump.
I spotted a similar question on here why tcpdump captures on half the packets
And the suggestion was that it was filtering duplicates sent and received by/at the interface. They were looking at the whole interface and not singling out specific ports. Here this does not appear to be the case, as I am using the dump on specific ports, with the source and destination ports for the traffic being different. Also looking the eth0 with the same traffic, I can see the all the captured packets that are being received by both the lo and eth0 filters.
For example I send 10 udp packets to both eth0 and lo, I get the following:
tcpdump -i eth0 udp port xxxx
10 packets captured
10 packets received by filter
0 packets dropped by kernel
tcpdump -i lo udp port xxxx
5 packets captured
10 packets received by filter
0 packets dropped by kernel
So it looks like tcpdump is filtering traffic only for the loopback, possibly grabbing every second packet. The timestamps seem to indicate this, as if I am sending packets at a rate of 1 packet per second, on the eth0 I see the packets captured occur at 1 second intervals. While on lo, the packets captured occur at 2 second intervals.
Is there some default configuration for tcpdump on a loopback that causes it filter every second packet?
Or am I misunderstanding something? It seems strange that tcpdump would operate differently depending on the interface choosen.
Related
I have this setup of systems where 3 VMs are connected to OVS.
On one system I am running UDP server on VM1 and VM3 and UDP client VM2.
In VM2, the packets from UDP client are destined to VM1 (destination address and port as mentioned in the code). But at the OVS, I have provided the rule where if the source IP is VM2 and destination is VM1, I am redirecting the UDP packets to VM3.
I am able to see the counter matching the rule and even I have observed the change of destination and port at the interface of the new destination in the wireshark.
But the problem is the I am not able to read the packets in the UDP server program in VM3
Can any one help please
EDIT : The below is the screen shot when trying to redirect packets from a TCP connection. I am not able to send the packet to the destination
For the virtual machine's networking stack to accept those redirected packets, you will have to rewrite the destination IP and Ethernet addresses as well.
I am using:
# tcpdump -i gphy -vv -B 28000 -s 120 -w log.pcap tcp portrange 10032-10001
to capture packets which I sent out from a host, and I notice all the packets with IP flags altered are missing, is there away to capture all packets even if IP flags is not correctly programmed ?
This non deterministic behaviour could occur due to multiple potential reasons, such as incorrectly setting the 'Do Not Fragment' bit in IP flags, which may result in the packet being dropped. Perhaps you should ensure that you've correctly set the IP flags field to check whether the packet is being sent. If it is being sent (and not being dropped during transmission), with the given command you should be able to capture all packets (provided they match the filter).
Im trying to implement an "opt ack" attack
this attack involves sending ack packets before the packets arrive thus increasing the tcp windows and creating a big load on the network channel.
im using scapy to record traffic between a client and a server
and then i send the client ack packets one after one
i have two problems:
i need to shut down the kernel sending packets automatically
(it makes the attacker send reset packets)
also i need to fix the timestamp and checksum
can you help me with at least the first problem?
The first problem (RESET packets) can be fixed by installing iptables rules. It worked really well for me in my implementation of packet replay.
iptables -A OUTPUT -p tcp -d "DST IP ADDR" --sport "SRC PORT" --tcp-flags RST RST -j DROP
The kernel has no knowledge of segments sent by Scapy, it doesn't have a socket bound to the port you are using (see here) so it sends RST segments as an answer to the ACK segments.
You can add an iptable rule to drop these on the attacker's machine:
iptables -A OUTPUT -p tcp --tcp-flags RST RST -s source_ip -j DROP
If you change segments, Scapy will recompute checksums before resending it.
Note that invalid checksums when recording trafic could be caused by checksum offload on your machine and can be solved with ethtool command:
ethtool --offload ethX rx off tx off
For the timestamps, I assume you are talking about TCP Timestamps option. You can forge them before resending the segment with Scapy TCP options:
ACK = IP(...)/TCP(..., options=[("Timestamp", (TS_value, TS_ecr))])
I'm new in this site.
This is my problem: I have 3 different sources (IP: 192.168.1.1,192.168.1.2 and 192.168.1.3) that send data (via UDP) to a single receiver (IP 192.168.1.4) on the listening port 8900 (same port for every source). I can redirect the traffic on 3 different listenging port on the receiver (one for every source i.e. 192.168.1.1 --> port 8910, 192.168.1.2 -->8920 and 192.168.1.3 --> 8930), 3 processes are listening on those ports.
If i loose a packet during the transmission, the process that should have been received this packet, try to send a retransmission request to the sender that is wrongly localhost instead of the original sender.
Is there a way to maintain the orinal IP during the redirection?
Sorry for my bad English and thanks for your help.
getsockopt(...,SO_ORIGINAL_DST) is what you are looking for.
(assuming that you did iptables -j REDIRECT or similar )
I have a linux server with two NICs (eth0 and eth1), and have set eth0 as default in "ip route." Now I would like to receive multicast packets on eth1. I have added "224.0.20.0/24 dev eth1 proto static scope link" to the routing table, and I connect as follows:
sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
// port 12345, adress INADDR_ANY
bind(sock, &bind_addr, sizeof(bind_addr));
// multicast address 224.0.20.100, interface address 10.13.0.7 (=eth1)
setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, &imreq, sizeof(imreq));
According to ip maddr it connects to that group on the right interface, and tshark -i eth1 shows that I am actually getting multicast packets.
However, I don't get any packets when calling recvfrom(sock). If I set "ip route default" to eth1 (instead of eth0), I do get packets via recvfrom. Is this an issue with my code or with my network setup, and what is the correct way of doing this?
(update) solution: caf hinted that this might be the same problem; indeed: after doing echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter I can now receive multicast packets!
caf's comment that this is a duplicate of receiving multicast on a server with multiple interfaces (linux) answered this! (And I post this as an answer for clarity.) Namely, an echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter resolves my issue.
Try adding a netmask and specifying 10.13.0.7 as the gateway in your routing table entry.
Correct, assuming you had two NICs with a default gw on only one of them.
Multicast uses unicast routes to determine path back to the source. It means, if multicast path is different from unicast path, then a multicast path will exit. It's a loop prevention mechanism called RPF check.
In this case the application bound to a NIC effectively was forced to join the IGMP over where as the unicast routes were learned from the other NIC with default gateway. So the check was failing. Thus no data.
You don't need to add any static routes. It should just work when you change the rp_filter value to 0.