Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@johannesthoma
Copy link
Contributor

@johannesthoma johannesthoma commented Aug 21, 2024

Purpose

NETIO.SYS is a more convenient BSD style networking (TCP/IP, UDP/IP) kernel API
that is used by modern drivers (NDIS 6, WinDRBD). Originally
the intention was to have something to get networking with
WinDRBD working (http://github.com/johannesthoma/WinDRBD be sure to
pick the 1.2 branch, 1.1/stable will NOT work), a goal
that is already met by this version. Other features (like
UDP/IP receive from and the whole
RAW socket implementation) are still missing. What should work
is:

  • creating a WSK socket
  • Bind socket to an address
  • UDP SendTo
  • TCP connect
  • TCP send/receive
  • Listen/Accept
  • Closing sockets
  • Where it makes sense the upper driver's completion routine is called.

This is my first 'real' ReactOS project so please let me know
what you think. Especially coding style might not always match
the ReactOS style (I am used to Linux kernel style) so I am
asking for your understanding. Thanks a lot for reviewing this.

Best regards,

- Johannes

Proposed changes

Adding a new (NT 6) driver: NETIO.SYS

TODO

UDP/IP ReceiveFrom
Raw sockets
regression tests
and lots of other small stuff ...

@johannesthoma johannesthoma requested a review from ThFabba as a code owner August 21, 2024 12:48
@github-actions github-actions bot added the drivers Kernel mode drivers and frameworks label Aug 21, 2024
@oleg-dubinskiy oleg-dubinskiy added the enhancement For PRs with an enhancement/new feature. label Aug 21, 2024
Copy link
Contributor

@JoachimHenze JoachimHenze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution!
Ok, some style-nitpicks indeed.
In general you can find our Coding-style document here: https://reactos.org/wiki/Coding_Style

I will do some suggestions, that you can simply apply first, but I will also mention some things, that you have to push yourself afterwards, because I cannot use the github suggestions-feature for suggestions of such wide-scrope: First and foremost a suggestion of wide-scope:

  • we do indent with spaces, not with tabs. 4 spaces per indentation level. That part is mandatory.

Like I said: accept some of my manual suggestions first, before doing the 4-indent-push afterwards yourself.

@JoachimHenze JoachimHenze added the NT6+ For PRs that aim at implementing NT6+ functionality. label Aug 21, 2024
@JoachimHenze JoachimHenze changed the title NETIO.SYS driver [NETIO] Add NETIO.SYS driver Aug 21, 2024
@JoachimHenze
Copy link
Contributor

JoachimHenze commented Aug 21, 2024

I am done with giving the most important style-hints, each in at least one location for now. I will let you act on them now, and will re-review later, whether they will have been applied consistently. Others will review the functional aspects later as well.

@johannesthoma
Copy link
Contributor Author

Hi Joachim & others,

Thank you for the review, I really should have read the CodingStyle first. Will push tomorrow
again, should I amend or make a new commit? Please let me know what you prefer.

Best regards,

  • Johannes

@SigmaTel71
Copy link
Member

Will push tomorrow again, should I amend or make a new commit? Please let me know what you prefer.

Either works as our merging pull request procedure most of the time is squashing commits related to the pull request into a single one. You can both safely append new commits to your codebase and amend changes.

johannesthoma added a commit to johannesthoma/reactos that referenced this pull request Aug 23, 2024
As reviewed by Joachim Henze (reactos#7262)
I used indent to fix most of the coding style issues:

    indent -o %2 -gnu -bli0 -hnl -nut -i4 -l110 -bls -ncs -npcs -nprs -nsaf -nsob -lp -cli4 -cbi0 %1
@johannesthoma
Copy link
Contributor Author

Does the driver work on 2k3sp2 now? Can you post a screenshot of it running in there?

Hi, as I already posted in the Development channel, NETIO.SYS now works also on Windows Server 2003 and Windows Server 2003 SP2. Attached is a screenshot (you don't see much except that the driver is running)
netio-windows-2003

@johannesthoma johannesthoma force-pushed the jt/netio-sendto-and-tcpip-works-rebased branch from ad0dec2 to eec2c28 Compare October 21, 2025 14:59
@johannesthoma
Copy link
Contributor Author

Hi Timo, I just rebased the patch squeezing most of the commits.
AFD->tdihelpers is separate, netio is separate and there is also the TCPIP patch
regarding the 0 ports. Do you want to take a look over it again?

@johannesthoma johannesthoma force-pushed the jt/netio-sendto-and-tcpip-works-rebased branch from eec2c28 to 85488d6 Compare October 21, 2025 15:15
@github-project-automation github-project-automation bot moved this from New PRs to Approved by reviewers in ReactOS PRs Oct 23, 2025
@binarymaster binarymaster changed the title [NETIO] Add NETIO.SYS driver [NETIO] Implement I/O driver for block devices over network Oct 24, 2025
@binarymaster
Copy link
Member

Some suggestions for commit messages before merging:

-TCPIP.SYS: Always depend on TCP/IP implementation for unspecified port (0).
+[TCPIP] Always depend on TCP/IP implementation for unspecified port (0)
-[TDIHELPERS] Moved TDI helpers from AFD driver to separate directory
+[TDIHELPERS] Move TDI helpers from AFD driver to separate directory
-[NETIO] NETIO.SYS driver
+[NETIO] Implement I/O driver for block devices over network

I also renamed PR title accordingly, if the responsible merger decides to use Squash & Merge strategy.

In bind(2) when specifying 0 as port the TCP/IP (or also UDP/IP)
driver is supposed to assign a free port number in the range
0xc000-0xffff. In the ReactOS TCP/IP driver there are two implementations
of this mechanism: one in the "TCP/IP library" and one in the
lwip TCP/IP stack.

The TCP/IP library can reassign local ports to connection oriented
sockets as soon as the address file (TDI) of a former connection
oriented socket is closed. The problem that arises with such a
port reuse is that the TCP/IP stack keeps the socket for a time
period specified in the TCP/IP RFC (the state is called FINWAIT
if I remember correctly). So if the same port is assigned twice
we will get an status 0xc000020a (STATUS_ADDRESS_ALREADY_EXISTS)
from the lwip implementation, thereby making new connections
to the same remote IP/port pair with a newly created socket
impossible.

The solution I came up with (and which solves the can't connect
any more issue) is to simply not use the TCPAllocatePort() mechanism
when the port is 0 (unspecified) which lets the lwip implementation
choose a free port (honoring sockets in FINWAIT state).
We want to use the TDI helper functions also in the NETIO.SYS
driver which comes with the next commit. The code was modernized
a bit (usage of DPRINT, doxygen style comments) but other than
that it was left unchanged.
This patch adds the NETIO.SYS driver to ReactOS. NETIO.SYS
is part of Windows since NT6 (Vista).

The driver is not feature complete (meaning some functionality is
unimplemented) but does its job quite good for what it originally
was written for (which is getting WinDRBD working on
ReactOS/Windows 2003 SP2).

The driver re-uses parts of the AFD.SYS driver, namely those
functions that ease communitating with the transport device
interface (TDI). Other than that, following features are implemented
and should work:

 * TCP/IP networking: connect, listen, accept, read, write
 * UDP/IP networking: write

So in a nutshell TCP/IP support is completed, UDP support is
partially complete and ICMP support does not exist yet.
In particular the listen/accept mechanism allows one to write
kernel side TCP servers that one can connect to via the internet.
@johannesthoma johannesthoma force-pushed the jt/netio-sendto-and-tcpip-works-rebased branch from 85488d6 to d7a04be Compare October 24, 2025 12:20
@johannesthoma johannesthoma changed the title [NETIO] Implement I/O driver for block devices over network [NETIO] NETIO.SYS driver: An in-kernel BSD-style networking API Oct 24, 2025
@johannesthoma
Copy link
Contributor Author

So I changed the commit messages and the pull request title to something more meaningful.
Thanks to @binarymaster for pointing that out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

drivers Kernel mode drivers and frameworks enhancement For PRs with an enhancement/new feature. NT6+ For PRs that aim at implementing NT6+ functionality.

Projects

Status: Approved by reviewers

Development

Successfully merging this pull request may close these issues.