Home/ Questions/Q 6046979
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T07:18:04+00:00

I’ve seen it asked elsewhere but no one answers it to my satisfaction: how

  • 0

I’ve seen it asked elsewhere but no one answers it to my satisfaction: how can I receive and send raw packets?

By “raw packets”, I mean where I have to generate all the headers and data, so that the bytes are completely arbitrary, and I am not restricted in any way. This is why Microsofts RAW sockets won’t work, because you can’t send TCP or UDP packets with incorrect source addresses.

I know you can send packets like I want to with WinPCAP but you cannot receive raw information with it, which I also need to do.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First of all decide what protocol layer you want to test malformed data on:

    Ethernet

    If you want to generate and receive invalid Ethernet frames with a wrong ethernet checksum, you are more or less out of luck as the checksumming is often done in hardware, and in the cases they’re not, the driver for the NIC performs the checksumming and there’s no way around that at least on Windows. NetBSD provides that option for most of it drivers that does ethernet checksumming in the OS driver though.

    The alternative is to buy specialized hardware, (e.g. cards from Napatech, you might find cheaper ones though), which provides an API for sending and receiving ethernet frames however invalid you would want.

    Be aware that sending by sending invalid ethernet frames, the receiving end or a router inbetween will just throw the frames away, they will never reach the application nor the OS IP layer. You’ll be testing the NIC or NIC driver on the receiving end.

    IP

    If all you want is to send/receive invalid IP packets, winpcap lets you do this. Generate the packets, set up winpcap to capture packets, use winpcap to send..

    Be aware that packets with an invalid IP checksum other invalid fields, the TCP/IP stack the receiving application runs on will just throw the IP packets away, as will any IP/layer 3 router inbetween the sender and receiver do. They will not reach the application. If you’re generating valid IP packets, you’ll also need to generate valid UDP and implement a TCP session with valid TCP packets yourself in order for the application to process them, otherwise they’ll also be thrown away by the TCP/IP stack

    You’ll be testing the lower part of the TCP/IP stack on the receiving end.

    TCP/UDP

    This is not that different from sending/receiving invalid IP packets. You an do all this with winpcap, though routers will not throw them away, as long as the ethernet/IP headers are ok. An application will not receive these packets though, they’ll be thrown away by the TCP/IP stack.
    You’ll be testing the upperpart of the TCP/IP stack on the receiving end.

    Application Layer

    This is the (sane) way of actually testing the application(unless your “application” actually is a TCP/IP stack, or lower). You send/receive data as any application would using sockets, but generate malformed application data as you want. The application will receive this data, it’s not thrown away by lower protocol layers.

    Although one particular form of tests with TCP can be hard to test – namely varying the TCP segments sent, if you e.g. want to test that an application correctly interprets the TCP data as a stream. (e.g. you want to send the string “hello” in 5 segments and somehow cause the receiving application to read() the characters one by one). If you don’t need speed, you can usually get that behaviour by inserting pauses in the sending and turn off nagel’s algorithm (TCP_NDELAY) and/or tune the NIC MTU.

    Remember that any muckery with lower level protocols in a TCP stream, e.g. cause one of the packets to have an invalid/diffferent IP source address just gets thrown away by lower level layers.

    You’ll be testing an application running on top of TCP/UDP(or any other IP protocol).

    Alternatives

    • switch to another OS, where you at least can use raw sockets without the restrictions of recent windows.

    • Implement a transparent drop insert solution based on the “Ethernet” or “IP” alternative above. i.e. you have your normal client application, your normal server application. You break a cable inbetween them, insert your box with 2 NICs where you programatically alter bytes of the frames received and send them back out again on the other NIC. This’ll allow you to easily introduce packet delays in the system as well. Linux’ netfilter already have this capability which you can easily build on top of, often with just configuration or scripting.

    • If you can alter the receiving application you want to test, have it read data from something else such as a file or pipe and feed it random bytes/packets as you wish.

    • Hybrid model, mainly for TCP application testing, but also useful for e.g. testing UDP ICMP responses. Set up a TCP connection using sockets. Send your invalid application data using sockets. Introduce random malformed packets(much easier than programming with raw sockets that set up a TCP session and then introduce lower layer errors). Send malformed IP or UDP/TCP packets, or perhaps ICMP packets using WinPcap, though communicate with the socket code to the winpcap code so you’ll the addresses/port correct, such that the receiving application sees it.

    • Check out NS/2

    • 0