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).
Related
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.
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))])
Can use tcpdump to capture socket data ?. Since , at the listener end i'm freqyently getting some additional info along with send message.
In between client and end listener , one edge server and one application server is running, not sure at which point that additional info is being added. To troubleshoot, I tried to use tcpdump to capture the socket data. But I couln't capture it.
Can someone please tell me, tcpdump is not fit to capture socket data?. if so, then which one is correct one to do this.
Note: I'm Using CentOS
tcpdump can capture data base on port as following:
tcpdump tcp port 23 and host 210.27.48.1 -w temp.pcap
If you still can't capture any data, you can capture data for the interface to ensure your tcpdump is working:
tcpdump -i eth1 -w temp.pcap
ps: If your client and your server are on the same machine, you need to capture the lo interface.
I'm trying to implement tracert using tcp on Windows. I'm using Winsock. Socket I use is SOCK_STREAM.
The problem is how do I get the address of the host with the next TTL. As far as I get I cannot use recvfrom function in this case because TCP is a connection based protocol so recv is equal is recvfrom in this context.
I tried to use getpeername but I still get only target node's IP address.
Moreover. Setting even TTL = 0 to the IP packet still results finds its way to the target machine and I get the response.
tracert (or traceroute) doesn't work with TCP but with ICMP (like ping). The TTL should be started by 1 and then incremented by 1 until the destination was reached.
More can be found on http://en.wikipedia.org/wiki/Traceroute#Implementation
(Using Linux)
Creating TCP packets using raw sockets - it turns out that calculating the checksum is the bottleneck for me, in high performance networks. Since the NIC's would support checksum offloading, and ethtool also says that it is enabled, I hoped that I could use checksum offloading.
But it seems that the checksum is not calculated, when I use raw sockets. Is there a way to enable tcp checksum offloading using raw sockets?
Edit:
Actually the behaviour of my machine/NIC (Thinkpad x201) does not seem to be too logical: when sending packets with normal tcp sockets, all checksums are wrong, on the loopback interface as well as between machines. Funnily the other machine silently delivers the packets though ?
Edit2: Ok now I just looked at the packets on the wrong machine, the offloading works. But when I leave the tcp_checksum field 0, it does not get filled in, it simply stays 0.
I have the same problem here: sent TCP or UDP packet in raw socket but can't take advantage the NIC whose checksuming-offloading is on. Wish there is a setsockopt() or ioctl() type of function that enable checksuming-offloading on the raw socket.
For the question why wireshark shows packets to have checksum errors but destination host accepts all the packets anyway, the reason is that wireshark (through winpcap etc if on windows) captures packets before the packets reached the NIC from OS. The packets don't have the checksum fields filled correctly by OS or application --- this is what checksum offloading feature on NIC is for.
The question is, how to enable NIC to do checksum offloading on a raw socket.