Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Network data transfers to/from user mode

2»

Comments

  • Mark_HolidayMark_Holiday Member Posts: 32

    Thank you, Peter!

    The NDIS Virtual NIC driver with KMDF at lower edge was my initial thought here. I have done this before (using the "WDM at lower edge" example as my model), and is probably the reason I was brought on this project. (Like yourself, it has been a few years) :/

    The reluctance I had with this solution was the requirement that the network traffic at the lower edge actually has to interface with the user-mode PDC, and is the impetus for this whole thread. Employing the "inverted call" method for that data transfer is one possibility that I have learned about here.

    But if your requirement is to bridge these PDCs to "real" LAN/WAN hardware... I'm not sure that's the same piece of software as we were just describing above (upper edge protocol, lower edge PDC) -- Because now you have software that has lower edge that talks to your PDC and also lower edge that talks to a REAL NIC. I'm not sure how you make that work, frankly.

    I agree that this part of the puzzle requires more investigation.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,240

    Employing the "inverted call" method for that data transfer is one possibility that I have learned about here.

    So, ignoring the whole “bridge to a real NIC” thing, I wouldn’t hesitate for a second to use Inverted Call ... just be sure to have your user-mode PDC post a bunch of pending IOCTLs and handle their completion reasonably efficiently (completion ports are nice for this). It’d be very convenient... you need to send a message from the protocol to the PDC, you pick one of those pending IOCTLs off a manual Queue, copy the NBL to the IOCTL OutBuffer, and WdfRequestCompleteWithImformation and you’re good to go.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MBond2MBond2 Member Posts: 234

    But I am still confused as to what you need. These UM components obviously communicate via network protocols now right? It could be TCP or UDP or CDP, but it is some kind of network protocol, or else there would be no use in a virtual NIC - they couldn't use it unless they use the winsock APIs somehow

    Windows has support for bridging interfaces in box since at least Vista IIRC, so just making a bridge driver would be a waste of time

    if the IP spaces conflicted, it would be far cheaper to buy a router and program a hairpin NAT than to develop a driver like this

    perhaps you want your PDC to stop using a network protocol? In that case, the sockets opened by the other UM processes would have to terminate in your driver, and you could then use inverted call to pass the data up to PDC. KM sockets are well understood and long supported, but the performance difference versus well (or even poorly) coded UM sockets is usually small and they are much more complex to work with (just as everything is harder in KM)

    perhaps you want to multi-plex or proxy your PDC in some way? That might be reasonable, but I don't read that into anything you have said.

    I'm intrigued, but confused

  • Mark_HolidayMark_Holiday Member Posts: 32

    @MBond2 For the ease of this discussion, we basically want our own virtual network stack, including our own virtual miniport (VNIC).
    I have performed this type of work before; one major difference with this project, however, is that the "lower edge" of our miniport does not go out to real hardware or some other kernel component, but rather that traffic interfaces with a user-mode component (PDC), that then talks to the devices for the RF network. For the purposes of this discussion, we are only concerned with facilitating communication between the VNIC and the PDC, i.e. we do not care about the PDC communication with the real RF device(s).

    So the impetus for this thread was how to best facilitate that kernel-mode network traffic to/from the user-mode PDC. From this discussion, it appears that the inverted call model provides a solution.

    Perhaps this thread got off on a tangent because I did not do an adequate job initially in describing the effort. I hope this helps to clarify.

  • Pavel_APavel_A Member Posts: 2,756

    Mr. Holiday, everybody here already understood that you've written a NDIS miniport some time ago and want to build on that.
    But probably you've learned kernel drivers before normal usermode network (socket) techniques.
    Otherwise, why the "PDC" cannot just open a socket on local host and listen, and the client software connect to it?
    This would save cost and time of developing a VNIC. On the down side, there will be no driver to write and bill the customer for.

    Sorry, you've asked to abstain from condescending tone. I've failed :(

    -- pa

  • Mark_HolidayMark_Holiday Member Posts: 32
    edited December 2020

    @Pavel_A Thank you for your comment. No offense taken with the tone of your comment. :)

    What you describe is how the system currently operates. For this next project, we eventually would like to move the network interface outside of the PDC component; but we would like to support 3rd party network applications, e.g. web browser. Also, as I mentioned, there is now a requirement to support bridging network interfaces.

    Wouldn't a VNIC/KMDF solution with its "lower edge" talking to the PDC provide/allow for both of these requirements??

    If so, then the complexity of this solution - again - becomes:
    how to control the flow of network traffic to/from lower edge of VNIC (kernel mode) to/from PDC (in user mode).

    That is the problem I originally asked about here; but in trying to ask this is in simple, general terms I must have done a really poor job explaining it because I received many suggestions to just write a user-mode socket application. However, I do think that some folks did manage to figure out what I was trying to ask, as they have suggested the inverted call method to facilitate such communication.

  • Pavel_APavel_A Member Posts: 2,756
    edited December 2020

    we eventually would like to move the network interface outside of the PDC component; but we would like to support 3rd party network applications, e.g. web browser.

    Mark, frankly, the more I read and re-read this thread, the more my confusion grows.
    So well, you wish to take some server functionality out of the "PDC" and put it (modified? optimized?) into one or more separate modules.
    Why these modules need a separate network interface (VNIC) to talk to the PDC and clients? Why not over the normal sockets?

    OTOH if you want to route traffic from Windows apps to the RF network beyond the "PDC", then yes, a VNIC may be a way to connect that network to the OS. But...

    how to control the flow of network traffic to/from lower edge of VNIC (kernel mode) to/from PDC (in user mode).

    ... your VNIC does not have a lower edge. It has no lower kernel layers and no hardware. It will talk to NDIS at its upper edge - being a normal MAC miniport - and talk to the "PDC" thru a kernel socket, or new ioctl based interface via a helper device object.
    How to control the flow of that? Well, it is your project... there are so many sync devices in kernel and user mode...

    -- pa

  • anton_bassovanton_bassov Member MODERATED Posts: 5,192

    ... your VNIC does not have a lower edge.

    Actually, it does, but this lower edge part is not a physical network - instead, it deals with the userland app/service that provides/consumes data, effectively simulating the physical network.....

    Anton Bassov

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,240

    Can this thread just quietly end now? Please?

    I think Mr @Mark_Holiday has gotten as much help from us this specific issue as he’s likely to get. If he has additional questions, let him ask in a separate thread.

    But we’re going in circles at this point.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Mark_HolidayMark_Holiday Member Posts: 32

    Actually, it does, but this lower edge part is not a physical network - instead, it deals with the userland app/service that provides/consumes data, effectively simulating the physical network.....

    Bingo!

    Thank you all for you help on this.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE