locked
FwpsAcquireClassifyHandle0 Fails RRS feed

  • Question

  • In my BIND REDIRECT classifyFn this is what im trying to do.

    My Experiments with the layer have come to a standstill as I am unable to acquire the Classify Handle

    void NTAPI bindclassify( _In_ const FWPS_INCOMING_VALUES0 *inFixedValues, _In_ const FWPS_INCOMING_METADATA_VALUES0 *inMetaValues, _Inout_ void *layerData, _In_opt_ const void *classifyContext, _In_ const FWPS_FILTER1 *filter, _In_ UINT64 flowContext, _Inout_ FWPS_CLASSIFY_OUT0 *classifyOut ) { SOCKADDR_IN *pSockAddrIn; char buf[32] = "192.168.152.129"; PVOID* writableData; FWPS_BIND_REQUEST0 *bindRequest; UINT64 *classHandle = NULL; NTSTATUS status; status = FwpsAcquireClassifyHandle0( NULL,//(void*)classifyContext, inMetaValues->flags, classHandle ); if (!NT_SUCCESS(status)) { goto Exit; } status = FwpsAcquireWritableLayerDataPointer0( classHandle, filter->filterId, inMetaValues->flags, &writableData, classifyOut ); if (!NT_SUCCESS(status)) { goto Exit; } bindRequest = (FWPS_BIND_REQUEST0*)writableData; //classifyOut->actionType = FWP_ACTION_BLOCK; pSockAddrIn = (SOCKADDR_IN*)(&(bindRequest->localAddressAndPort)); pSockAddrIn->sin_addr.S_un.S_un_b.s_b1 = 192; pSockAddrIn->sin_addr.S_un.S_un_b.s_b2 = 168; pSockAddrIn->sin_addr.S_un.S_un_b.s_b3 = 152; pSockAddrIn->sin_addr.S_un.S_un_b.s_b4 = 129; FwpsApplyModifiedLayerData0( classHandle, (PVOID)writableData, FWPS_CLASSIFY_FLAG_REAUTHORIZE_IF_MODIFIED_BY_OTHERS ); if (!NT_SUCCESS(status)) { goto Exit; } Exit: FwpsReleaseClassifyHandle0( classHandle ); }

    What went wrong?



    Friday, May 16, 2014 6:42 PM

All replies

  • Aaaaaa! My Bad I had messed up  during registration of my callout! It works fine now

    However I am still unclear on a few details!

    1)I find the local address and port are zeroed out when I cast the BINDREQUEST(WritableData) to SOCKADDR_IN. Is it an expected behavior(is it because the TCB will be populated with these details at the network later later on?)?

    2) What others details and boundary checks etc do I need to place in?

    and Above all

    3) On a multihomed system why do I need to "ignoredefaultroutes = disabled" for the bindredirect or even normal app bind to work. Is it because after multiple default routes are populated in the routing table the older default route is disabled to make the route selection process faster?(Just a guess)

    Regards

    Umar Yaqoob

    Friday, May 16, 2014 7:09 PM