Frankly I'm rather ignorant on OneX, so bear with me if I say something stupid or obvious.
When you write a LWF, you should conceptually think of your filter driver to be part of the NIC; your filter gets to tinker with everything the NIC does, before the rest of the OS sees it. (And vice versa — when the OS talks the to the NIC, your filter gets to tinker with the command before the NIC sees it.) So what you should do is read the behavior of what a miniport is supposed to do for OneX, then ask yourself "how would I shoehorn that behavior on top of an otherwise-ignorant miniport driver?".
In NDIS6, every NIC has one or more "ports". A typical Ethernet NIC has exactly one port, and it's also called the "default port". OneX authz state is a property of the port. A typical Ethernet NIC will take no specific action, in which case it will get a default port assigned with default parameters (i.e., no authz required).
A miniport can, at any time, update the port parameters by issuing NDIS_STATUS_PORT_STATE. This status indication informs the OS the new control & authz states.
In theory, a LWF might be able to glue basic OneX support onto a miniport simply by issuing this status indication once initially, then again each time the OneX state changes. In order to correctly fill out the other fields of the status indication (e.g., XmitLinkSpeed), you'll probably need to cache these fields from the NIC. You can query this structure from the lower layer at any time by querying OID_GEN_PORT_STATE.
You should also trap that status indication if it comes from below you (i.e., from the miniport or a lower LWF). If that happens, take the values from the lower layer, merge in values for the fields you care about (control & authz), then propagate the status indication.
I can't promise that this is sufficient to get things working, since I don't know of anybody who's done this before.
