SendPacketToAdapter() causes crash…

Home Forums Discussions Support Portal SendPacketToAdapter() causes crash…

This topic contains 1 reply, has 2 voices, and was last updated by  Vadim Smirnov 8 years, 3 months ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #5257

    cozmik
    Participant

    SerpentFly,

    I’ve recently found out the hard way that the SendPacketToAdapter() method will cause Windows XP SP3(running in VMware Server) to fault and reboot, IF the sent to adapter isn’t valid for the operation. Following is a short example scenario:

    On my computer, the list of available adapters includes a “WAN Network Interface (IP)” adapter. If I attempt to send a generic Ethernet packet through this adapter, using SendPacketToAdapter(), it causes my Windows XP SP3 VMware Server instance to fault and reboot. I didn’t test for this on other computers.

    My questions are:

    1) If I can use the the method PacketRequest() to determine an adapter’s SendPacketToAdapter() ability, what values for _PACKET_OID_DATA.Oid and Data[0] should I use? I’ve searched my installation and examples of WinpkFilter for file “ntddndis.h”, which should contain constants for these fields, as specified in the Help File, but I can’t find it. My gut feeling is there will be no guidance in such file for this situation and that you’ll have to give direct guidance.
    2) If question #1 method doesn’t apply, then how do I determine, exactly, if an adapter is able to execute SendPacketToAdapter() without faulting the computer?

    My quick fix? Currently, when developing the list of available interfaces, I check the exposed MAC address. If the MAC address is 0, then I don’t include it in a selectable list. It seems to be a crude fix. If the adapter MAC address is 0, and I try to send a packet through it, it crashes the system, so I just don’t let my application use these “invalid” adapters.

    IMO, the hook firewall driver should NEVER CRASH the computer when manipulated via API methods. I know this type of blanket statement is idealistic, but it’s just good practice. Programmers will do things in testing, sending invalid packet bytes, setting invalid modes, setting invalid filters, etc. Any invalid input to or use of an adapter should fail gracefully, returning a standard error result or a “true/false” error indicator. It’s a pride thing to a programmer to prevent fatal crashes in their programs no matter how it’s used, especially via your own helper API! Just my 2 cents on it.

    Thanks in advance for your help. 8)

    ~Cozmik

    #6761

    Vadim Smirnov
    Moderator

    On my computer, the list of available adapters includes a “WAN Network Interface (IP)” adapter. If I attempt to send a generic Ethernet packet through this adapter, using SendPacketToAdapter(), it causes my Windows XP SP3 VMware Server instance to fault and reboot. I didn’t test for this on other computers.

    This is a know issue. If you try to send packet with incorrect Ethernet header on the NDISWANIP (WAN Network Interface (IP)) it may crash the NDIS.SYS. NDISWAN uses Ethernet addresses from the packet header to identify the exact WAN link (actually bytes from Ethernet header used as an index in the WAN links table). If the index for the table is wrong NDISWAN references incorrect memory and crashes. So you should be very careful with what packet you send on NDISWANIP.

    The only way it can be fixed is checking Ethernet header for WAN interface in driver and dropping packets with incorrect headers (not associated with any active WAN links). However, from other side this would add some sort of limitation to what you can do with WInpkFilter (I can imagine the situation with layered filters which uses Ethernet addresses for some sort of remapping). So dealing with this issue was left to developers who use WInpkFilter. By request this special check can be added to the driver custom build.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.