Error: Failed writing to device (And some other questions)

Mar 22, 2013 at 7:02 PM
Edited Mar 26, 2013 at 11:03 PM

I'm getting: InvalidOperation exception: Failed writing to device. WinPcap Error: send error: PacketSendPacket failed error (No inner exceptions). This does not happen with all packets, just with one in particular. Could it be the fact that the packet's size is 7221 bytes?

Since doesn't support reassembling the packets and http chunks I implemented this feature on my own. Everything works fine (reassembling and decompressing). When I'm trying to send the packet, I send it as a whole expecting for either Pcap or the router to split it into fragments. Isn't that the case?

If it's not the case, does that mean that I have to manually split the packet into fragments or is there something else that I am missing? The code for constructing the packet:

Edit: Removed the code since I don't believe it's really helpful (Just an ordinary packet constructed by ethernet, ip, tcp and http layers). Let me know if it's really needed and I'll put it back up (Was taking too much space making the whole post harder to read).

Also, I have a few other questions I would like to ask if I may:

1) Is Pcap.Net discontinued or should I expect future releases? The reason I'm asking this is because it seems that the latest update was done almost a year ago and it's a shame to stop here (Only a few important things left).

2) What is the difference between IpV4Layer.Destination and IpV4Layer.CurrentDestination? Was unable to find something online and I can't think of anything (since the protocol only uses 1 destination address).

3) The user guide states "Note that transmitting a send buffer with Transmit() is much more efficient than performing a series of SendPacket(), because the send buffer is buffered at kernel level drastically decreasing the number of context switches.". Since I'm only transmitting 1 packet per loop (1 packet every time I receive one) do you believe that it's worth it to set-up a timer and transmit all the packets every, let's say, 50 miliseconds? Or is this whole timer thing going to decrease overall performance since it's "over-optimizing" it (e.g. not required if the send and receive ratio is 1:1)? Also, do I have to create a new SendBuffer every time I call Transmit? Can't find a way to clear it (Was thinking of adding packets to the buffer and transmitting them when its length exceeds a threshold or when a timer times out).

4) How would I add padding at the end of the packet? I tried adding a PayloadLayer with 0x00 bytes at the end of the packet but for some reason it's as if it is never added (Nothing changes).

5) I couldn't find any information about communicator.Mode (PacketCommunicatorMode). There seems to be 4 values, what do they mean?

6) Is there a bug with PacketDeviceOpenAttributes.NoCaptureLocal? It seems that I'm capturing data sent by myself even though it's being set.
static PacketDeviceOpenAttributes attributes = PacketDeviceOpenAttributes.NoCaptureLocal | PacketDeviceOpenAttributes.MaximumResponsiveness;

using (communicator = adapter.Device.Open(65536, attributes, readTimeout)) {
//Displaying each packet's IP source, and I can see my own IP.
Also, is there a difference (assuming that it actually works) between using that attribute and using a filter that
filters out traffic with IP source of my own?

Forgot to mention, this is a great wrapper.

Thank you very much,
I appreciate your help,
Mar 31, 2013 at 9:27 AM
Hi Orestis,

Can you try and dump the packet into a pcap file and link it here so I can take a look at this particular packet?

Regarding your other questions:

1) Pcap.Net is not discontinued. However, I haven't had much time to work on it recently. I'm sure you can understand that - since I'm a sole volunteering developer. If you look at the source code history you can see that there has been some progress towards the next release in the last months.
2) It's actually documented. When the IP packet has an IP routing option, there's a difference between the final destination of the packet (Destination) and the destination the packet should be heading now (CurrentDestination). I've changed IP to support both features after I saw Wireshark shows the final destination instead of the current destination.
3) I'm pretty sure that if you're only transmitting a few packets at a time there won't be much difference, and I'll go with the simpler approach - not using Transmit(). Note that this is basically a WinPcap question since Pcap.Net only wraps this WinPcap functionality. See here:
4) What kind of padding are you looking for? Can you give me an example packet you're trying to create and why?
5) This is also actually documented. From the source:
    /// <summary>
    /// Working modes for packet communicator.
    /// </summary>
    public enum class PacketCommunicatorMode : int
        /// <summary>Capture working mode.</summary>
        Capture         = 0x0, 

        /// <summary>Statistical working mode.</summary> 
        Statistics      = 0x1, 

        /// <summary>Kernel monitoring mode. </summary>
        KernelMonitor   = 0x2, 

        /// <summary>Kernel dump working mode.</summary>
        KernelDump      = 0x10  
6) In general this should work. Again, only wraps WinPcap functionality. Note however that as documented: "this flag applies to the specific PacketCommunicator opened with it only.".

I hope this helps,

Mar 31, 2013 at 3:03 PM
Edited Mar 31, 2013 at 3:04 PM
Hello Boaz,

Thank you for your reply. I was able to fix the error by manually fragmenting the packet.

You've been very informative regarding the rest of the questions. As for the padding, I'm specifically talking about an ARP packet. Here is a screenshot of the packet being captured from wireshark (This is not sent by Pcap)


There are 18 bytes of padding in the Ethernet layer (though I don't know why they are there, it should be in the ARP layer I believe). Here's another screenshot from a slide from which shows the 18 bytes of padding:


ARP packets sent with pcap do not have this padding and are only 42 bytes (where they should be 60). I don't know whether this affects anything; it still seems to work even without the padding.

As for the PacketDeviceOpenAttributes.NoCaptureLocal, I don't know why it doesn't work but I'm happy enough with using filters to filter out traffic sent from myself.

I didn't know you are a sole developer on this, I would volunteer to help develop this wrapper but I'm still on my way on learning C/C++ (I'd also be grateful if you could recommend a book).

Thanks again,
I appreciate your help,
Apr 1, 2013 at 10:17 AM
Hi Orestis,
I'm glad this helps.

Regarding the padding.
As far as I understand, the padding is Ethernet padding, to get to the minimum size of Ethernet packets.
I think the device takes care of it.
This data is inferred in Pcap.Net, since in addition to padding there can also be Ethernet FCS and even though it belongs to Ethernet, it depends on the next layer length (for example, if the next layer is unknown, it's impossible to infer how much of the data is padding).
I might be able to allow inserting it manually, but I'm not sure this would help much. As you've mentioned, it works without it.

Regarding C/C++, I can't really recommend a book, I don't use programming books so much.

Apr 1, 2013 at 11:23 AM
Thank you that's all I needed to know. I appreciate your help.