I need to set the DSCP field of packets sent from a specific (tcp) socket in windows XP.
It seems that the GQOS API should serve this purpose (see http://blogs.msdn.com/wndp/archive/2006/07/05/657196.aspx) but I really, really, can't find any working example or figure how to use it on my own.
I would be very grateful if anyone of you have a working example he/she could share.
However, the following workarounds are not acceptable:
Using the QOS2 api - it's only available on Vista and up (and I'll use it there)
Using the TC api - it's not specific to a given socket (it tries to match outgoing packets to a filter) and requires admin rights to use 3.
Using SetSockOpt with IP_TOS - it's deprecated in XP, was not meant for setting the DSCP field and requires changing the registery.
Thanks!
Related
I have a Windows application (APP) and Audio Processing Object (APO) loaded by AudioDG.exe that communicate via gRPC:
APP part that is written in C# creates server via Grpc.Core.
APO part creates client via grpc++.
Server is on 127.0.0.1:20000 (I can see it's up and listening with netstat -ano).
I can confirm that APO is loaded into audio device graph by inspecting it with process explorer.
Everything worked like a charm on Windows 8 and 10, but on 11 it cannot communicate at all - I get either Error Code 14, Unavailable, failed to connect to all addresses or 4, Deadline Exceeded.
After enabling debug traces, I now see "socket is null" description for "connect failed" error:
I0207 16:20:59.916447 0 ..\..\..\src\core\ext\filters\client_channel\subchannel.cc:950: subchannel 000001D8B9B01E20 {address=ipv4:127.0.0.1:10000, args=grpc.client_channel_factory=0x1d8bb660460, grpc.default_authority=127.0.0.1:10000, grpc.internal.subchannel_pool=0x1d8b8c291b0, grpc.primary_user_agent=grpc-csharp/2.43.0 (.NET Framework 4.8.4470.0; CLR 4.0.30319.42000; net45; x64), grpc.resource_quota=0x1d8b8c28d90, grpc.server_uri=dns:///127.0.0.1:10000}: connect failed: {"created":"#1644240059.916000000","description":"socket is null","file":"..\..\..\src\core\lib\iomgr\tcp_client_windows.cc","file_line":112}
What I've tried so far:
Updating both parts to the latest grpc versions.
Using "no proxy", "Http2UnencryptedSupport" and other env variables.
Using "localhost" or "0.0.0.0" instead of "127.0.0.1".
Updating connection to use self signed SSL certificates (root CA, server cert + key, client cert + key).
Adding inbound / outbound rules for my port, and then disabling firewall completely.
Creating server on APO side and trying to connect with the client in APP.
Everything works (both insecure and SSL creds) if I create both client and server in C# part, but as soon as it's APP-APO communication it feels blocked or sandboxed.
What has been changed in Windows 11 that can "block" gRPC?
Thanks in advance!
In your input you write:
Server is at 127.0.0.1:20000
Further looking at the logs, you can see that:
The server is located at
grpc.server_uri=dns:///127.0.0.1:10000
Based on the question posed and the amount of data provided, I would check which port the server is really using and which port the client is looking for a connection on.
The easiest way to do this is to use the built-in Resource Monitor application. On the Network tab, in the TCP Connections list, you can find the application and the port it uses.
You can also use the PowerShell command
Test-NetConnection -Port 10000 -InformationLevel "Detailed"
Test-NetConnection -Port 20000 -InformationLevel "Detailed"
At least this is the first thing I would check based on what you described.
Regarding your question about the changes in Windows 11, I do not think that this is something that's causing problems for you. However, Windows 11 has additional security features compared to Windows 10, try disabling the security features completely as a test. Perhaps this will help solve the problem.
As for ASP.NET Core 6.0 itself (if I understood the version correctly), then there is a possibility that the server part, working not in the sandbox of the programming environment, still does not accept the client certificate. At the program level, you can try to fix this by adding the following exception to the code:
// This switch must be set before creating the GrpcChannel/HttpClient.
AppContext.SetSwitch(
"System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
// The port number(5000) must match the port of the gRPC server.
var channel = GrpcChannel.ForAddress("http://localhost:5000");
var client = new Greet.GreeterClient(channel);
More troubleshooting issues with ASP.NET Core 6.0 Microsoft described in detail here.
https://learn.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-6.0
I hope it was useful and at least one of the solutions I suggested will help solve your problem. In any case, if I had more information, I think I could help you more accurately.
I'm trying to get my head around SNMP for a project I'm working on. After I failed miserably getting it to work in my company's network, I set up a simple 3-device network to test things on, consisting of two Windows 10 PCs and a manageable switch between them.
I installed the optional feature "SNMP" on both PCs, made sure the service is running correctly and configured both services to accept SNMP queries from each other. I made sure to open up UDP port 161 in both PCs firewalls. Then I got the Net-SNMP binaries in order to use SNMPGET and SNMPWALK. As an alternative, I set up the SNMP extension for PHP through xampp (since I want to use PHP in my project once I get SNMP to work). Finally, I installed wireshark to monitor what exactly is going on and this is what I found:
When I try SNMPGET or SNMPWALK either through cmd or as a PHP command, I always get a timeout message. Wireshark is showing the get-next-request leaving one PC and arriving correctly on the other, so the network connection itself is working fine. But the receiving PC never sends a response. As I said, I'm pretty new to SNMP and I'm at a loss as to why this is happening. As I understand it, the optional feature for Windows 10 comes with its own SNMP agent, correct? If so, what could cause it to simply ignore an incoming request from a valid source IP?
The funny thing is that this even happens when I try to send an SNMP query to 127.0.0.1. I have no idea what I'm doing wrong...
Thanks to the comment of Lex Li, I was able to finally figure out which step I made a mistake with:
When setting up the SNMP service, under the security tab, I had to add 'public' as an accepted community name (with READ-ONLY rights). I figured since 'public' is sort of the standard read-only community, it would be accepted by default, which apparently it is not.
Alternatively, I guess I could have added my own communtiy name, but I didn't try that since I only want to read some values through SNMP anyways and read-only access is all I need for that.
Thank you very much Lex Li, I'm off to continue my project now!
I was trying to find traceroute program implementation for MS Windows that can be used by regular user (with no admin rights) and I could not find any. Those I could find (like tracetcp or nmap) require PCAP library and in order to install winpcap I think administration rights are required.
I don't know much about Windows internals but I'm wondering what is the 'magic' behind. If tracert shipped by MS with Win OS works fine for regular user (but it can use ICMP only) then is there any issue (technical limitation) with setting TTL for TCP/UDP packet by regular user and receiving respective response on the socket such as:
ICMP: TTL expired in transit
UDP: port unreachable
and probably few others (like TCP RST, ICMP host unreachable etc)?
So basically:
if there is no issue why there is no reasonable traceroute implementation
for windows?
if there is a technical limitation for TCP/UDP then why
original MS ICMP traceroute works fine for non admin users?
I know that the most popular linux traceroute with -T option (for using SYN probes) requires root priviliges too but I'm assuming it's just because it does not want to complete full TCP handshake and sending RST after receiving SYN-ACK may be restricted for root. Anyway as longs as TTL can be set by reqular user (for UDP it seems to work fine) then I would imagine TCP traceroute completing full TCP handshake should be possible to implement for non root linux users?
And by the way ICMP traceroute also needs admin rights because of using RAW sockets but surprisingly for Windows it does not seem to be an issue.
Sadly, the simple answer to your question is "no, there is no native way to do that on a Windows box".
I am a bit unsure about your specific usecase, but one route to go is evaluate if Power Shell has more functionality to help you out. Jose Baretto from Microsoft wrote an article about Power Shell equivalents for common networking commands. You can find it here:
https://blogs.technet.microsoft.com/josebda/2015/04/18/windows-powershell-equivalents-for-common-networking-commands-ipconfig-ping-nslookup/
Failing that, your only option is (as you mention yourself) 3rd party tools, and you'll be hard press to find one that doesn't require elevated privileges.
I am trying to create a DTLS "connection" using Schannel under Windows (I am testing under recent Windows 10 version, so all DTLS versions supported by Schannel should be available)
I tried starting from working code to establish a regular TLS connection by following the documentation:
InitializeSecurityContext with null input on the first pass, SECBUFFER_TOKEN & SECBUFFER_ALERT on output
AcceptSecurityContext with SECBUFFER_TOKEN & SECBUFFER_EMPTY on input, SECBUFFER_TOKEN & SECBUFFER_ALERT on output.
Repeat the two steps until they succeed, and then move on to using Encrypt/DecryptMessage
This works perfectly fine in stream mode (ISC_REQ_SEQUENCE_DETECT | ISC_REQ_REPLAY_DETECT | ISC_REQ_CONFIDENTIALITY |
ISC_RET_EXTENDED_ERROR | ISC_REQ_ALLOCATE_MEMORY | ISC_REQ_STREAM)
If I try to substitute STREAM with ISC/ASC_REQ_DATAGRAM, my InitializeSecurityContext succeeds with SEC_I_CONTINUE_NEEDED as expected, but my very first AcceptSecurityContext then fails with SEC_E_INVALID_PARAMETER.
I have tried setting grbitEnabledProtocols of my SCHANNEL_CRED to 0 to use the defaults as documented on both sides, I also tried setting it to SP_PROT_DTLS1_X, and I still get the Invalid Parameter return from my first ASC. I have also tried the DTLS_1_0 constants just in case.
Also, all security protocols are enabled by default in my registry settings.
From my understanding of the DTLS RFC, my code is failing at the HelloVerifyRequest step, and, again from my understanding of the RFC, this part requires that the security provider generates a cookie from a few parts of the ClientHello message as well as the source's IP address. However, I could not find any documented way to pass this information to the ASC function.
(I think? :) ) I have searched the entire internet for any working example usage of DTLS under Schannel without any luck. On stackoverflow, I found this question that simply mentions that it is supported:
Is DTLS supported by Schannel on Windows 7?, and the linked MSDN article is just a high level overview.
I searched for any usage of the constants that are related to this feature... I searched for any usage of the constants that are related to this (ISC_REQ_DATAGRAM, SP_PROT_DTLS*, SECBUFFER_DTLS_MTU, ...) and the only thing I could find on all search engines I could think of were either copies of sspi.h or sites that index the constants in the Windows API...
I know DTLS is well supported by other implementations (OpenSSL etc), but I would really prefer to stay with Schannel, as other parts of my code currently work just fine with Schannel in TLS mode.
From Microsoft:
There is no documentation for implementing DTLS using Schannel. Known and persistent doc gap.
There are a few differences, but a TLS client or server can be adapted to DTLS fairly easily (a number of customers have done this successfully).
Set SCHANNEL_CRED.grbitEnabledProtocols to SP_PROT_DTLS1_X.
When calling AcceptSecurityContext, pass the client’s SOCKADDR via SECBUFFER_EXTRA.
MTU can be set via SetContextAttributes using constant SECPKG_ATTR_DTLS_MTU where the buffer is just an pointer to a ULONG. [Default is 1096 bytes.]
When ISC/ASC return SEC_I_MESSAGE_FRAGMENT, send this fragment and call ISC/ASC again, in a loop, to get the next fragment (without trying to read data from the network).
Implement timeout and retransmit logic in your application (since
schannel does not own the socket).
When receiving fragments, schannel will attempt to eliminate
duplicates, re-order and re-assemble, if possible.
SCHANNEL_SHUTDOWN does not apply to DTLS.
You can use https://github.com/mobius-software-ltd/iotbroker.cloud-windows-client As a sample to implement DTLS on windows
It does not uses SChannel but netty library.
MQTT-SN And CoAP are both supporting DTLS under this project.
BR
Yulian Oifa
How can i filter (allow, deny etc) outgoing packets in Windows? I want to search in TCP or UDP packet types to find in the data segment for example this "387602304fd236e048125453b1fa10c980e9dad4fa7f3f5dd2497c2e8b2b" and drop/block/deny the packet, if it matches the search hex string.
I have already tried WIPFW and PKTFILTER but they only serve IP source, dest, port etc filtering. They don't inspect the packet's data.
I think Berkeley Packet Filter doe's that job, but it's for unix...
Here is some to filter packet in windows:
WinDivert Free open source project work on Windows 7, 2008 or upper. network layer.
WinpkFilter 3.0 Commercial, Windows XP and upper. datalink layer
pcausa, Commercial. datalink layer
Windows Filtering Platform Packet Modification Sample
A sample to create callout driver that WinDivert use, you should now to implement kernel driver. network layer.
you can use SmartSniff in windows.
Starting from version 1.10, you can filter unwanted TCP/IP activity during the capture process (Capture Filter), or when displaying the captured TCP/IP data (Display Filter)
You want application level filtering then, (just changing the payload). If you want to be able to drop, I know you can hook into Winsock, which will allow you to capture packets as they go out and set up a filter there. Windows seven also added to their firewall, so you could use that API to grab outbound packets; I'm not sure if it will allow you to specifically alter the payload data, though.