[Winpcap-users] FW: Service crash after update to WinPcap networking (II)

Guy Harris guy at alum.mit.edu
Tue Apr 8 02:58:12 UTC 2014

On Apr 3, 2014, at 2:34 AM, "J. M." <carpe7 at hotmail.com> wrote:

> Sent again, as I don't receive the copy from the list.
> From: carpe7 at hotmail.com
> To: winpcap-users at winpcap.org
> Subject: FW: Service crash after update to WinPcap networking
> Date: Fri, 28 Mar 2014 12:14:08 +0000
> The other server has just crashed. So the problem is not restricted to a single machine.
> We are thinking about updating HP NIC drivers and firmware (dated January 2011), hoping that an outdated driver/firmware could make WinPcap more prone to participate in these crashes.
> There is another strange behaviour: we have applied a safety mechanism to detect malformed packets; it compares the len property of the pktHeader returned by WinPcap to the datagramSize derived from the IP datagram header. If they don't match, a log message is written, and the packet is discarded.
>                     Public Const EthernetHeaderSize = 14
>                     Public Const BasicIPHeaderSize = 20
>                     Private _MaxDatagramSize As Integer = 65535
>                     Private _MaxEthernetPacketSize As Integer = EthernetHeaderSize + Me._MaxDatagramSize
>                     ...
>                     Dim errBuf As New StringBuilder(WinPcap.Constants.PCAP_ERRBUF_SIZE)
>                     Dim session = WinPcap.Driver.pcap_open(Me._DeviceName, Me._MaxEthernetPacketSize, WinPcap.Constants.PCAP_OPENFLAG_MAX_RESPONSIVENESS + WinPcap.Constants.PCAP_OPENFLAG_NOCAPTURE_LOCAL, 1, IntPtr.Zero, errBuf)

So you're certain that the link-layer header type is DLT_EN10MB, right?  (If you're capturing on an Ethernet adapter, that's probably the case, but programs should *ALWAYS* check the result of pcap_datalink() or its equivalent in whatever wrapper you're using.)

>                     ...
>                     While Not cancellationTokenSource.IsCancellationRequested
>                         Dim pktHeader As IntPtr = IntPtr.Zero
>                         Dim pktData As IntPtr = IntPtr.Zero
>                         Select Case WinPcap.Driver.pcap_next_ex(session, pktHeader, pktData)
>                             Case 0
>                                 Continue While
>                             Case Is < 0
>                                 Throw New Exception(WinPcap.Driver.pcap_geterr(session))
>                         End Select
>                         Dim header = DirectCast(Marshal.PtrToStructure(pktHeader, GetType(WinPcap.pcap_pkthdr)), WinPcap.pcap_pkthdr)
>                         If header.len > EthernetHeaderSize + BasicIPHeaderSize Then 'Ethernet header + IPv4 header (without options)

So you're certain that these are all IPv4 packets, right?

I.e., either you have set a filter of "ip", or something else that only matches IPv4 packets, or you check the Ethernet type of the packet and ignore all packets where it's not 0x0800?

>                             Dim datagramSize As UShort = Marshal.ReadByte(pktData, EthernetHeaderSize + 2)
>                             datagramSize <<= 8
>                             datagramSize = datagramSize Or Marshal.ReadByte(pktData, EthernetHeaderSize + 3)

(I assume "Or" is Visual Basic's bitwise-OR operator.)

>                             If header.len >= EthernetHeaderSize + datagramSize AndAlso datagramSize <= Me._MaxDatagramSize Then
>     'Process the packet
>                                 ...
>                             Else
>                                 Logging.Write(TraceEventType.Verbose, "Discarded packet with datagramSize {0} and header.len {1}", datagramSize, header.len)
>                             End If

So what is the error message reporting as the datagramSize value and the header.len value?

> Well, it is happening, very significantly I would say.
> My questions are:
> -- Is it common that packets are this malformed?

If these packets aren't IPv4 packets, then this doesn't indicate that they're malformed, it just indicates that they don't look like valid IPv4 packets.

> -- Is my understanding right that in PCAP_OPENFLAG_MAX_RESPONSIVENESS mode WinPcap delivers complete datagrams to the application (if the internal buffer is big enough)?


> I'm not precluding IP fragmentation, rather I wonder whether individual datagrams (be they fragments or not) are delivered as indisivible units to the application.

Yes, they are.

More information about the Winpcap-users mailing list