[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)?
Yes.
> 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