Thanks, I hope it'll be useful in your experiments. As for looking more realistic, I think it does the job; when I checked with Wireshark checked how different applications (e.g., games, programs) were communicating with their servers, I saw that they were sending empty SYN packets (i.e., no options) in order to initiate the TCP handshake.

Although hping3 does not let you specify TCP options, it still lets you append them as raw data. Despite that, only one application that I tested actually sent TCP (+options) back to its server. However, this specific server still ACK'ed my packets and proceeded normally, even if I did not send these so-called options. In any case, it will be easy to just append the options as raw data at the end of the packet buffer, for targets that actually discriminate based on options.

None of the real-world applications that I tested used fragmentation, and they all tagged their packets with "DF" (do not fragment); due to that, I did not really look into how fragmentation would affect this.

The reason I specifically included CIDR support, something that both nping and hping3 lack in their source IP parameter, was that ISPs or mid-route routers could block "nonsense" traffic (e.g., a source IP outside of the ISP or even country's allocated range) coming from a client; this is called "egress filtering." However, in a DHCP-assigned scenario, you still have thousands of IP addresses in your subnet/range to spoof, which should not get caught by this filtering. Ultimately, because the source IP would be coming from an entire range of addresses, firewalls (and CDNs) will have a harder time detecting a pattern as to block it.

As for defending against TCP SYN flooding in general, you could use "SYN Cookies" (https://en.wikipedia.org/wiki/SYN_cookies) as to expand less resources in keeping connections open. Unfortunately, in a residential ISP scenario where you only have one "real" IP address, your spoofed source IP would be chosen from a range of otherwise-legitimate addresses; those addresses (upon unexpectedly receiving SYN-ACK from your targeted server) would usually respond back to the original server with a RST packet as to terminate the connection, making it so that your "half-open" connections (the goal of SYN flooding) do not get to last as long. Lastly, this tool only really lets you flood packets as quickly as possible; if you have (or rent) multiple datacenter-grade bandwidth, powerful x86_64 CPUs, and lots of "real" IP addresses at your disposal, there would be little that your target could actually do to prevent you from DDoS'ing them. At that point, in the worst-case scenario, they could go "scorched earth" and reject all traffic from entire countries' ranges (saving their CPU/memory usage), but your packets would still continue getting routed there, and you could still saturate their download line.

As for how this could be made faster (without just throwing more cores and computational power at it), the entire overhead is on the Linux Kernel's "sendto()" side; perhaps writing a kernel module to communicate directly with the underlying NIC is the way to go.