- Read the interface metric from the registry.
- Assign an automatic metric to an interface if a registry value is not available.
- Determine the automatic metric from the link speed. The metric for the loopback interface is always 1.
- Identify 127.x.x.x addresses as on-link addresses.
- Modify the neighbor cache to map all 127.x.x.x addresses to the loopback address (127.0.0.1).
- Create a single entry for all 127.x.x.x addresses instead of one entry per address. This entry belongs to the loopback address.
CORE-7484
RtlConvertUlongToLargeInteger and RtlConvertLongToLargeInteger are
obsolete NT routines that assign a 32-bit integer to LARGE_INTEGER.QuadPart.
Replace all driver/DLL usages with inline .QuadPart assignments or
standard C/C++ casts. This removes unnecessary function calls.
CORE-19438
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 Server 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.
The netio driver is licensed under the MIT license, see the file
netio.c for more details.
Have fun with it :)
Signed-off-by: Johannes Khoshnazar-Thoma <johannes@johannesthoma.com>
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.
CORE-20300
- `NdisRegisterProtocol()`: Add a comment about `NDIS51`: the
`NDIS50_PROTOCOL_CHARACTERISTICS` structure is common to both
NDIS 5.0 and 5.1.
This is in contrast to the `NDIS50/NDIS51_MINIPORT_CHARACTERISTICS`
structures, see for example commit 3e169e3cb2 (r49961).
- Remove obsolete SOURCES file. Addendum to commit d9e83ed22d (r40142).
- Let it be `"NDIS"`, instead of variations of `"SIMN"`.
- Use matching `ExFreePoolWithTag()`.
- Remove a redundant `KeyInformation = NULL;`.
Addendum to commits e8861acfb2 (r12196) and 5658b2154c (r53045).
CORE-18791
Split Windows Server 2003 and Windows Vista behaviour in two different cases and make them used separately: when ReactOS target version is NT 5.2, use the 1st case, otherwise use the 2nd one instead.
Also, handle NdisPhysicalMediumNative802_11 case only for NT 6.0 and newer, since that's actually supported starting from NDIS 6.0, according to MSDN:
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/oid-gen-physical-medium
while for NDIS 5.1 and newer it's:
https://learn.microsoft.com/en-us/previous-versions/windows/hardware/network/ff560255(v=vs.85)
This fixes:
1. A critical regression with unavailable networking in ReactOS when 3rd-party NT5-compatible Ethernet/Wi-Fi drivers are used (both in VM and on real hardware) caused by commit 3842b59f75 from @EricKohl.
2. Failure to open Network Properties and Network Status from the Network tray icon (caused by the same commit too).
MSDN tells us this is done so for Windows XP and Server 2003 as well, and IF_TYPE_IEEE80211 is returned only in Windows Vista and newer, so the following Microsoft documentation is actually correct in this case:
https://learn.microsoft.com/en-us/windows/win32/api/iptypes/ns-iptypes-ip_adapter_info
(see the information about "IP_ADAPTER_INFO.Type" member below on that page)
!!!Please note that the behaviour of Vista+ case (e. g., when compiling ReactOS targeted as NT 6.0 and newer) remains unchanged after this fix (networking still may not work), so it still requires the proper support of 3rd-party NT6+ compatible network miniport drivers (by handling this case via the Vista/NDIS6-style way) for NT6 target!!!
CORE-20244
Use a KSEMAPHORE instead of a NotificationEvent to signal availability. This is to prevent satisfying the wait for multiple waiters, when only a single entry is on the list.
Fixes crashes on SMP builds.
Send OID_GEN_PHYSICAL_MEDIUM and OID_GEN_MEDIA_SUPPORTED query requests to NDIS.
This will enable us to distinguish wired and wireless ethernet adapters.
URLs are getting old. We have to
update URLs for documentation
purpose.
JIRA issue: CORE-19963
- Refresh old URLs.
- Add " (DEAD_LINK)" labels
to dead links.
- Use MS Learn links rather
than MSDN ones.
- Some dead links revived by
Web Archive.
- Don't change Wine Tests
and Wine Sync.
- Don't change 3rd party libraries.
- Don't append "redirected" labels.
Windows has all its network drivers inf files in 8.3.
This is an addendum to 0.4.15-dev-52-g 019f21ee1d
which moved us further away from our target.
The commit on its own was a good idea actually to get the inf into the drivers directory
and therefore simplifies adding and excluding drivers more locally (e.g. excluding works by
adding a single hashtag within the specific drivers CMakeLists.txt now).
But that cool feature doesn't require us to move away from our target.
For the record:
The historic netrtpnt.inf and netisa.inf (both 8.3) have been merged to
netne2000.inf (not 8.3) by 0.4.15-dev-2763-g 6924b8ff39
Unification of that was cool too,
but again: 8.3 is superior. Therefore netne.inf for that.
Worst of all: Since the .inf files did contain their filename within a comment also, that means
the historic renaming by the mentioned commit invalidated that comment.
netamd.inf fixed by restoring the ancient filename before 0.4.15-dev-52-g 019f21ee1d
netrtl.inf fixed by restoring the ancient filename before 0.4.15-dev-52-g 019f21ee1d
netne.inf I fixed the comment manually.
This is the network driver which is used for MSVPC 2007.
I spotted it during a WIP-backport-experiment of the driver, when compiling with GCC4.7.2, which warned about it.
GCC8.4.0 unfortunately is blind to that on master head, for unknown reasons. Not good.
MSVC github buildbot is also blind to that on master head, for unknown reasons. Not good.
We later found that at least Clang did also warn about it on master head.
* [SDK][VIRTIO][NETKVM] Make VirtIO a separate library
This is to avoid code duplication when more VirtIO drivers are brought in. This will also be used on development of a VirtIO XDDM GPU Driver.
* [VIRTIO] Sync with upstream
- Update TCP cached information only after updating adapter information
(so that TCPUpdateInterfaceIPInformation/TCPUpdateInterfaceLinkStatus
gets new status)
- Call netif_set_link_up/netif_set_link_down in TCPUpdateInterfaceLinkStatus
This fixes a lwIP requirement:
2007-07-13 Jared Grubb (integrated by Frédéric Bernon)
* [...] Be carefull for port maintainers to add the NETIF_FLAG_LINK_UP
flag (like in ethernetif.c) if you want to be sure to be compatible with
future changes...
* [TCPIP] Rename lwip library to lwipcore
* [TCPIP] Remove ReactOS-specific code from LWIP library
* [TCPIP] Synchronize LWIP code to 1.4.1
Update to LWIP 1.4.1 should have been done by bd3b0e8ef4
However, I was unable to find the exact revision used in this commit.
So, do the following
- take code from STABLE-1_4_1 commit on https://git.savannah.gnu.org/git/lwip.git
- cherry-pick LWIP 32aa9a41e2013e5ee6eee09317a848647e37badf (CORE-8978)
- cherry-pick LWIP c0b534e5318baf870e2152c70d4d11a3a86181f3
- add a ReactOS-specific change in src/api/tcpip.c (missing include)
- add ReactOS specific file CMakeLists.txt
NOTE: Changes are mostly in unit test files (not used) and CHANGELOG file.
CORE-7140
- The return value got lost when refactoring the setup function
- The check against 0xFFFFFFFF was meant to reject an empty EEPROM image
- Add missing PAGED_CODE(); macros
CORE-8724
Revert "[PSDK][AFD][VGADDI] Further build and MS PSDK compatibility fixes."
This reverts commit 99efc2ae50.
Revert "[PSDK] Sync winresrc.h with wine-8.20"
This reverts commit 3e83562aa7.
Revert "[OSK][PROGMAN] Fix resource file build."
This reverts commit 84e4ad0a82.
Revert "[PSDK] Use the new .rh files in winresrc.h"
This reverts commit f6fb7c48c9.
- windows.h:
* should define _WINDOWS_ and _INC_WINDOWS instead of _WINDOWS_H
* include winresrc.h if RC_INVOKED and not NOWINRES (Wine also agrees
with that)
* also, some .h included from there should _not_ be included if their
respective NO*** flags are defined.
- batclass.h: Use correct _WINDOWS_ guard.
- winsnmp.h:
* should define _INC_WINSNMP instead of _WINSNMP_H
* use _INC_WINDOWS instead of _WINDOWS_H
- afd.h, vgaddi.h: Use the correct guards.
- winnt.rh: Define the (SUB)LANG_* exactly as they are in the winnt.h,
otherwise we get macro redefinition compile errors.
NOTE: Ideally these .rh files should be auto-generated from their
corresponding .h files.
- afxres.h: Do not include the whole windows.h, but instead, only
the winres.h file, and only if RC_INVOKED is defined.
NOTE: Both afxres.h and winres.h do not really belong to the PSDK,
but belong instead to MFC. The reason why we have them here is twofold:
1. Wine used to have also winres.h (from where we got ours). This is
because the .rc resource files of some non-MFC modules were generated
with Visual Studio, which always includes afxres.h for these, and the
solution was to use a slightly less MFC-specific header: winres.h
(Wine commit cb08c82244673f26842e7a0766de90f091b5a493).
However, this winres.h has been since removed from Wine tree
(Wine commit 197f4059ab2af5f13f9c56faa26e3b4af902f869).
2. Few of our modules either use afxres.h or winres.h in their resource
files, and we still want to be able to compile them.
