Develop Reference

Grpc Client throws Grpc.Core.RpcException (Response protocol downgraded to HTTP/1.1.)

I spend the last three days (Reading Docus, Trying different vesions of VS and .NET, check questions in Stackoverflow, issues in github, ...) about my Grpc client, the server start fine but the client never work, I tried Grpcurl it's works fine but C# client never works and throws Grpc.Core.RpcException here is a smaple:
HResult=0x80131500
Message=Status(StatusCode="Internal", Detail="Bad gRPC response. Response protocol downgraded to HTTP/1.1.")
Source=System.Private.CoreLib
This issue happed in VS2019, VS2022 (Net5, Net6).
Is there anything that I can do reagrding this? because we are going to use Grpc on our next project.

Unable to anonymously connect to Mosquitto 2.0.5 on Ubuntu

I have the Mosquitto 2.0.5 snap (version 511) running on an Ubuntu Core 18 system. I made no modifications to the configuration, nor pass another configuration to Mosquitto.
On that same system I am running a .NET 5 application, that uses MQTTnet to connect to Mosquitto. I do not pass any credentials to connect to Mosquitto. However, I am unable to connect to Mosquitto 2.0.5, where I was able to connect to Mosquitto 1.6.12 before.
I do know of the increased security of Mosquitto 2.0 (and that is also the reason to upgrade), but the upgrade documentation clearly states that in the default configuration (no listeners) anonymous connections are still possible on localhost:1883. The strange thing is, that it all works when I run Mosquitto 2.0.5 and my application on Windows, but it does not work on Ubuntu Core (the target system).
Mosquitto 2.0.5 is logging the following when I attempt to make the connection:
New connection from 127.0.0.1:57362 on port 1883.
Client <unknown> disconnected, not authorised.
I use the following C# code (using MQTTnet) to make the connection:
var factory = new MqttFactory();
var client = factory.CreateMqttClient();
var builder = new MqttClientOptionsBuilder().
WithTcpServer("localhost", 1883);
client.ConnectAsync(builder.Build(), CancellationToken.None).Wait(MQTTBROKER_TIMEOUT);
Am I not understanding something, am I doing something wrong?
Any help is appreciated.
EDIT: I have been playing around a bit more, and it seems that by default the dynamic security plugin is loaded when using the snap, however I did not find anything in the configuration files about this. I guess that due to this, the authentication fails.
Then the next question arises, how can I find out what the default administrator user and its password are in this situation, as I need those to be able to add groups, clients and roles to the plugin.

So it looks like Mosquitto 2.0.2 and above has had some security changes, just add this to your mosquitto.conf file as it is mentioned here
listener 1883
allow_anonymous true

C# Custom Remote Desktop Client using RDP 8.0

I have searched MSDN forum for this, but it seems everyone(i think) suggests to revert to RDP 7.x (uninstall MS Update KB2592687).
I have an custom Remote Desktop client written in C#/WPF,the Remote Desktop ActiveX control is hosted inside a WindowsFormsHost control.
The app works well prior to update RDP 8.0 (MS Update KB2592687). If i uninstall the MS update(revert to RDP 7.1), the app works.
My RDP Client is used to connect to Virtualbox VRDP (Virtualbox 4.2.x), no authentication needed(Null). With RDP 8.0 installed, the Windows Remote Desktop Client(mstsc.exe) connects just fine, with much better responsiveness(RDP 8.0 enhancements); but my custom RD Client is unable to connect.
Upon further investigation, my custom RDP Client is not throwing any exceptions or firing the OnConnecting and OnLogonError or most of the other events.
What's odd is, it is ONLY firing these two events (in order)
OnAuthenticationWarningDisplayed
OnAuthenticationWarningDismissed
I also tested with RawCap(http://www.netresec.com/?page=RawCap) to see if my custom RDP Client is sending packets to Virtualbox VRDP prior to those events. Surprisingly, it's not even sending packets. (MS RD Client - mstsc.exe works fine.)
So it boils down to these events/method calls on my custom RDP Client, and unfortunately I'm stuck.
(Code is shortened for brevity)
AxMSTSCLib.AxMsRdpClient8 rdp = new AxMSTSCLib.AxMsRdpClient8();
rdp.OnAuthenticationWarningDisplayed+=new EventHandler(rdp_OnAuthenticationWarningDisplayed);
rdp.OnAuthenticationWarningDismissed+=new EventHandler(rdp_OnAuthenticationWarningDismissed);
rdp.Server = server;
rdp.AdvancedSettings8.RDPPort = 5050;
//No username/password since Virtualbox RDP authentication is set to *null*
//MS RD Client connects just fine to Virtualbox RDP without username/password
try
{
rdp.Connect();
}
catch (Exception ex)
{
}
putting a breakpoint on OnAuthenticationWarningDisplayed and OnAuthenticationWarningDismissed confirms both events are fired after Connect() method.
I suspect the ActiveX control, after the Connect() method is called, is trying to show a dialogbox(??); but i can't seem to figure out.
Has anyone else done some custom client using RDP 8.0? What are the prerequisites to have it working(code).
Many thanks! Would greatly appreciate it.

Solved this problem!
Just try to use AxMSTSCLib.AxMsRdpClient8NotSafeForScripting instead of AxMSTSCLib.AxMsRdpClient8
Here's working code (Delphi):
rdp:TMsRdpClient8NotSafeForScripting; // ***Instead of TMsRdpClient8 (!!!)***
...
if rdp.Connected<>0 then rdp.Disconnect;
rdp.Server:='192.168.1.1';
rdp.UserName:='User';
rdp.AdvancedSettings8.ClearTextPassword:='Password';
rdp.AdvancedSettings8.AuthenticationLevel:=2;
rdp.AdvancedSettings8.EnableCredSspSupport:=true;
rdp.AdvancedSettings8.NegotiateSecurityLayer:=false;
rdp.AdvancedSettings8.RelativeMouseMode:=true;
rdp.AdvancedSettings.BitmapPeristence:=1;
rdp.AdvancedSettings.Compress:=1;
rdp.AdvancedSettings8.SmartSizing:=true;
rdp.DesktopHeight:= Screen.Height;
rdp.DesktopWidth:= Screen.Width;
rdp.FullScreen:=true;
rdp.ColorDepth:= 15;
rdp.AdvancedSettings8.RedirectDrives:=false;
rdp.AdvancedSettings8.RedirectPrinters:=false;
rdp.AdvancedSettings8.RedirectClipboard:=true;
rdp.AdvancedSettings8.RedirectSmartCards:=false;
rdp.Connect;
P.S. And do not use the following property:
rdp.AdvancedSettings8.AuthenticationServiceClass

ZMQ via C# - clrzmq binding Windows XP fails but is OK on Win7

I have been been developing a platform using ZMQ (2.2) as the main communications layer. Earlier this week I decided to take the advice on the zeromq website and upgrade to the latest stable build 3.2.2
However after going through the pain of updating to the new API I was seriously disappointed to discover that there seems to be a problem with the clrzmq binding in that it fails to load the libzmq library on Windows XP (SP3) machines. I keep getting a SEHException exception?!
I was just wondering if anyone out there has had the same problem and if there is a workaround (or even better a fix) for it?
Cheers
:)
EDIT
Just to clarify, the library is loaded fine, I know this because the context is created without any issue. The problem occurs when the CreateSocket method is called on the context... see code snippet below
ZmqContext context = ZmqContext.Create();
ZmqSocket socket = context.CreateSocket(SocketType.REQ);
After adding tracing as suggested by Jakob, I get the following output
Assertion failed: Connection refused (..\..\..\src\signaler.cpp:310)
Any Ideas what this means?
EDIT
I should also mention that this issue does not happen on all the XP machines, only some of them. I have been trying to figure out what the difference is between the machines that work and the ones that don't. Without knowing this it would be far too risky to upgrade and release into a production environment.

Looking at the example you provided, you are binding to a REQ socket (Request, i.e. client socket), and also binding the REQ socket using wildcards. I am not sure how this will play out, but to me it does not make sense. I do not think this is supported but I cannot find or remember any documentation about binding to a REQ socket. Likely strange things will happen.
The REP (response) socket is the "server" end of a REQ/REP setup (request/response), where you bind the server side using a REP socket to an endpoint, either explicitly specified "tcp://127.0.0.1:5555" or using wildcards, e.g. "all interfaces", "tcp://*:5555". The client side would then connect using a REQ socket to an explicit endpoint address, "tcp://127.0.0.1:5555", no wildcards.
The server would do this:
ZmqContext context = ZmqContext.Create();
ZmqSocket socket = context.CreateSocket(SocketType.REP);
socket.Bind("tcp://*:5501");
And the client this:
ZmqContext context = ZmqContext.Create();
ZmqSocket socket = context.CreateSocket(SocketType.REQ);
socket.Connect("tcp://127.0.0.1:5501");
Apart from those issues, you should also make sure the firewall is not blocking and make sure the port is not already in use (using for example the NETSTAT command).
For ZeroMq addressing rules, see the zmq_tcp API documentation, and for the socket, see the zmq_socket API documentation.

Lync 2010 SDK - Calling a response group

I have a response group made of 2 agents. For the sake of clarification let's use the following:
Agent1: ag1#domain.com
Agent2: ag2#domain.com
Response Group: RG#domain.com
My code is based on the following walk through to establish an AV call with an agent:
http://msdn.microsoft.com/en-us/library/lync/hh378584.aspx
If I establish a call with Agent1 or Agent2 directly using their SIP address, the call goes through and everything works perfectly and I can even render the video from both sides.
If I establish a call with the Response Group however, and even if Agent 1 or Agent 2 take the call, it just ends with no error message and no exceptions thrown on my side.
The Sample application accompanying the SDK (AudioVideoConversation) also exhibits the same problems.
What's the reason for this? Is the SDK capable of handling response groups? If so, then how?
Edit: (1) Forgot to mention: Lync is in suppression mode!
Edit: (2) Further investigation lead me to this answer on the Lync Client Development forum: Forum Answer which to be honest is quite inconclusive and outrageous since the issue was raised in 2011 and the bug was replicated by MS.
Edit: (3) Question was raised again in the Lync Client Development forum, pending the Lync team bug reproduction Forum Answer
Edit: (4) The recent June updates for the client don't solve the issue either.