The iptables are stopped, whenever i tried to send packet with scapy i'm getting the packet is getting
RST after SYN/ACK
the iptables are stopped,
the packet are send from MACOSX to Linux OS
This is probably an RST packet sent by the MacOS IP stack.
Scapy (on the MacOS computer) sends a TCP SYN packet.
The IP stack of the Linux computer sends a TCP SYN-ACK packet (the port is open).
The IP stack of the MacOS computer receives the TCP SYN-ACK packet while it has not sent a matching TCP SYN packet. It sends a RST packet, as it is supposed to do.
You can use a firewall on the MacOS computer to prevent the IP stack from getting the SYN-ACK packet.
Related
Similar to How to set source address when sending using and UDP socket, but not identical:
I'm writing an experimental UDP packet relay.
The code works so far, but the problem is that the relayed packets have the address and port of the relay (instead of the original sender) as sending address in the outgoing packets, so any responses would also go to the relay, and not to the original sender.
Is there a standard way (without manipulating the packets directly) to do this?
Currently it has to work for IPv4 only.
It seems that packets sent through using gopacket/gopcap are somehow 'sent' as they are visible in a tshark trace:
444 143.613451037 127.0.0.1 → 127.0.0.1 UDP 66 6000 → 8888 Len=22
but these packets never arrive on a process on the same machine listening on 127.0.0.1:8888 (for example netcat -ul 8888).
Does anybody have any hints on why this is or things to try? As mentioned, the packets are in fact visible in a tshark trace... they just seem to completely vanish after that.
... irrelevant
out , err := pcap.OpenLive(*iface, 65535, true, -1 * time.Second)
out.WritePacketData(buf.Bytes())
... irrevelant
The idea is to construct packets and send them on lo so that a process listening on 127.0.0.1:<some port> can actually see those packets.
IP src/dst are both 127.0.0.1 and ethernet src/dst are both 00:00:00:00:00:00.
Edit:
As far as some more research goes it seems to be the case that sending packets with pcap bypasses IP network stacks in such a way that the packets can't be seen by processes. A workaround is to strip the lower levels of the packets in the trace and open a regular udp/tcp socket and send the payload through that socket.
As far as some more research goes it seems to be the case that sending packets with pcap bypasses IP network stacks in such a way that the packets can't be seen by processes. A workaround is to strip the lower levels of the packets in the trace and open a regular udp/tcp socket and send the payload through that socket.
I'm attempting to craft a raw TCP packet to send over Ether in a raw socket on a linux client and server. The special part of the TCP packet is that I'm attempting to use the raw data field of the TCP SYN packet and RST packet to send data back and forth (for a proof of concept about an unused part of the TCP protocol).
I've disabled RST packets from my iptables on the server.
In short, here's my current situation:
Client sends SYN with data is sent to server
Server receives a SYN packet without data
Server responds with a RST packet with data
Client receives a RST packet without data
But, using the same socket, I can successfully do this:
SYN without data sent to server
Server receives a SYN packet
Server responds with a SYN ACK packet with data
Client receives a SYN ACK packet without data
Client receives a PSH ACK packet with data
Can someone explain to me why the packets I send don't seem to make it to the server in the same way I send them?
Why am I receiving two packets (one with SYN ACK and one with PSH ACK) in my successful attempts?
SYN and RST packets seem to lose their data, but SYN ACK packets don't. Is this a firewall issue?
If so, how can I debug what's intercepting my packets?
Thanks!
Turns out the VMWare virtual adapter was modifying the packets in transit. When I did a packet capture on the host operating system, there were no issues transmitting data.
In a linux system, I use scapy to send a high frequency UDP ping. For example: each 20 milliseconds, send a UDP packet; a total of 100. But I can only get the first few ICMP port unreachable answer.
pkt = IP(dst=dst)/UDP(dport=RandShort())
ans,_ = sr(pkt*100, inter=0.02, timeout=3)
I tried to use tcpdump to capture packet and found that all UDP packets have been sent to the target machine, but only a few ICMP packet came back to the source machine. What would cause this?
If I use ICMP ping，this does not happen.
I guess:
may be caused by the target machine's system kernel parameter which process icmp packet
may be caused by the icmp packet routing switch strategies.
The rate of ICMP packets is hard limited by the kernel to prevent DDOS attacks. Usually to only 1 packet per second. Almost impossible to get anything faster than that in any external (internet) router. Example
(edit: solved -- see below)
This is my situation:
TL-MR3020 -----ethernet----- mbed
OpenWRT C/C++ custom networking stack
192.168.2.1 192.168.2.16
TL-MR3020 is a Linux embedded router
mbed is an ARM microcontroller.
On the network I just want them to exchange messages using UDP packets on port 2225. In particular, TL-MR3020 has to periodically send packets every second to 192.168.2.16:2225, while mbed has to periodically send packets every 50ms to 192.168.2.1:2225.
Everything was good untill I removed the network stack library from mbed (lwIP, not so lightweight for me) and written a new minimal stack.
My new stacks sends 5 gratuitous ARP reply just after the ethernet link gets up, then starts sending and receiving udp packets.
Now TL-MR3020 doesn't receive any UDP packet. In particular, with ifconfig I can see packets coming, but my application can't get them.
Also, if I connect my laptop instead of the TL-MR3020, I can see the UDP packets coming, using Wireshark. There's nothing wrong, except done for my application.
I have a node.js script that has to receive the packets, but it doesn't receive nothing, but if I send UDP packets from local to local, the script receives them.
I think that my application is OK also because neither SOCAT can receive the UDP packets using socat - UDP-LISTEN:2225.
I've already checked on TL-MR3020:
arp table has the correct ip-mac assiciation
destination MAC address matches the incoming interface
destination IP address matches the incoming interface
IP checksum: wireshark says good=false, bad=false
UDP checksum: wireshark says good=false, bad=false
So, I'm asking... what are the minimum requirements for a custom networking stack to send UDP packets?
SOLVED:
You need a good checksum in the IP header.
UDP checksum, my case, can be set to zero.
tcpdump is very helpful (thanks to AndrewMcDonnell)