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
Related
I have two console applications, A and B.
The application A was created for test purposes and works as expected.
The application B does not work although it is basically a copy-paste of A's code:
System.Console.Write("User Name: ");
string username = System.Console.ReadLine();
System.Console.Write("Password: ");
string password = ConsoleReadPassword();
System.Console.WriteLine();
//user and password required because I am also a privileged user
//(member of mqm group)
MQEnvironment.UserId = username;
MQEnvironment.Password = password;
//for application B this line throws exception with code 2538
var queueManager = new MQQueueManager("TEST.QUEUE.MANAGER", "CLIENT.CONN.CHANNEL", "localhost(1414)");
Error code 2538 means "Host not available" which is weird because application A has no problems connecting to the same host.
This is how the MQ Server looks in MQ Explorer:
Queue managers:
Queues:
Listeners:
Channels:
Two server channels
Channel auth records:
Default channel authentication record which prevents MQ admins from connecting to queue managers. It was slightly modified (added ~ prefix) so now it does not block anyone.
The MQ Server and applications are running on the same machine so imho network problems are excluded.
The queue manager error log does not report any errors but the general error log looks like this:
08/02/2016 15:15:23 - Process(13720.10) User([username])
Program(B.EXE) AMQ9202: Remote host 'localhost(1414)' not
available, retry later.
EXPLANATION: The attempt to allocate a conversation using TCP/IP to
host 'localhost(1414)' for channel (Exception) was not successful.
However the error may be a transitory one and it may be possible to
successfully allocate a TCP/IP conversation later.
For both application I use the same version of amqmdnet.dll: 8.0.0.4
Both programs A and B have the same target framework: 4.5
While testing I didn't tried to run the both applications in the same time and I checked in MQ Explorer if the channel is free (Inactive).
I also tried to change the name of resulting assemblies but with no effect.
Does anyone know what could cause application B to be unable to connect?
When using the hostname localhost networking is still involved, it just all happens inside the one machine. If application A is running in the same machine as your queue manager then having application A connect using the connection name localhost(1414) will certainly work but it is not necessary to make the connection like this (i.e. using TCP/IP) you could instead make a local bindings connection.
On the other hand, if you are using TCP/IP because application B is running on a different machine to where the queue manager is running, then using localhost(1414) will not work because localhost on one machine does not connect to localhost on another machine. You should change what is specified in the application's connection name from localhost(1414) to use the IP address (or hostname) of the queue manager's machine (followed as before with the port number).
Although I was unable to find the cause of the problem the solution was to simply
delete and re-create the project.
This is what I tried before and what led me to this action:
In B I removed and then added back the reference to amqmdnet.dll - not working
I created yet another project (let's call it C): console application, same code - working
I renamed* the C project with the same name as B - still working
*The name of the non-working project contained a dot so I thought that this could cause the problem - it was not the case.
I try to deploy my Mongo database in Mongolabs, everything works fine, and I create a new database. Please see my connectionstring.
public DbHelper()
{
MongoClientSettings settings = new MongoClientSettings()
{
Credentials = new MongoCredential[] { MongoCredential.CreateCredential("dbname", "username", "password") },
Server = new MongoServerAddress("ds011111.mongolab.com", 11111),
//ConnectTimeout = new TimeSpan(30000)
};
Server = new MongoClient(settings).GetServer();
DataBase = Server.GetDatabase(DatabaseName);
}
but when I try to connect the database it's shows error like:
Add "?connect=replicaSet" to the end of your connection string if connecting to MongoLab.
new MongoClient("mongodb://username:password#ds011111.mongolab.com:11111/db-name?connect=replicaSet")
This JIRA ticket has some details: https://jira.mongodb.org/browse/CSHARP-1160
Basically the default is to connect to a replica set member. But MongoLab's Single-Node settings are actually a single node replica set and this causes us to not trust it. Appending ?connect=replicaSet to your connection string will force the driver to move into replica set mode and all will work.
Found that info here.
I am replacing the connection string method in like below.
new MongoClient("mongodb://username:password#ds011111.mongolab.com:11111/db-name")
Now it's solved.
Please see the answer from Paul Lemke.
Make sure your current ip address is white-listed in mongo db server.
If you change your internet provider new IP needs to be white-listed.
Make Sure your auth db is set correctly.
I ran into this issue when I mentioned only the DB i wanted to connect to , and my auth db was different (other than admin db ).
The db-name in this line is considered as the auth DB .
new MongoClient("mongodb://username:password#ds011111.mongolab.com:11111/db-name?connect=replicaSet")
Then you can change the selected DB Later
mDb = mClient.GetDatabase(mongoDBName);
Same Error Message but not encountered with a MongoLabs deployment.
I just encountered the same error listed in the title with an Asp.Net Core App. My issue was due to an IOC configuration issue.
In my IOC container, my wrapped MongoClient instance was configured with a dependency transient lifestyle.
Per The MongoDb C# Driver:
It is recommended to store a MongoClient instance in a global place,
either as a static variable or in an IoC container with a singleton
lifetime.
I promoted the lifestyle of my object to a singleton and it resolved the issue.
I am using:
.Net Core 2.0
Mongo C# Driver version 2.5
Castle Windsor for my IOC version 3.3.0
Please reference the C# Driver Client section:
http://mongodb.github.io/mongo-csharp-driver/2.5/reference/driver/connecting/#re-use
Make sure the database username is also case sensitive. I ran into this issue because of case sensitivity of the username.
It's related with MongoDB connection error. Probably you don't have permissions or you didn't specify the allowed IPs in MongoDB. Please check for example in MongoDB Compose if you are able to connect with your MongoDB Atlas. If you won't be able to connect, that means that you have wrong MongoDB connection string.
I had the same issue. I was able to connect to MongoDB Atlas Using MongoDb Compass, but using the same connection string in a C# project I got the error "A timeout occured after 30000ms selecting a server using CompositeServerSelector... ---> System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (61): Connection refused 192.168.1.254:53".
In my case the problem was caused by my Internet provider router. Switching the connection to my iPhone's 4G hotspot solved the connection issue.
The port 10255 was blocked by my Internet provider/firewall rules.
Opening this port at client side fixed the issue.
In my case, while trying to execute the application with docker compose, I forget the environment variables. The problem was resolved by adding the correct environment variables.
I had this issue and turned out the database server was 2 hours behind. Once I fixed its time, the timeout issue was resolved with it.
I am working with a program that is meant to publish to and read from an existing TIBCO EMS hosted on a server separate from the program. I have referenced the sample code provided with the TIBCO installation, resulting in a big chunk of the program. Here is the code snippet that I am having troubles with:
1 QueueConnectionFactory factory = new TIBCO.EMS.QueueConnectionFactory(serverUrl);
2 QueueConnection connection = factory.CreateQueueConnection(username,password);
3 QueueSession session = connection.CreateQueueSession(false, Session.AUTO_ACKNOWLEDGE);
When line 1 runs, it goes through alright. When line 2 runs, it goes through alright, however, the connection object is null, resulting in an error during line 3 where a NullReferenceException occurs.
I would have at least expected that line 2 would return some sort of error to show that the request timed out, the credentials were wrong, the url is inaccessible, or at least something to let me know what the issue is, but there is nothing like that, until it hits line 3.
Does it have to do with the configuration of my application? All I have done to get this working is include the TIBCO.EMS.dll as a reference and worked with the code from there.
Could it have something to do with the fact that I am connected to a VPN that requires a proxy? If so, how can I set up that proxy in my code?
Any help would be greatly appreciated. Thank you.
The issue was that I was using the wrong version of the .NET framework to work with the Tibco integration. The version I was using was farther along than the original.
It would think that your server URL is incorrect.
try different urls maybe like tcp://localhost:7222 (where localhost can be the IP/Name of the remote server)
install EMS locally on you workstation and see if you can connect to it. (Default admin with no password)
I am trying to connect to a remote queue using c#.
I tried many ways to connect to the remote queue but it always fails with common errors like: MQRC_CHANNEL_CONFIG_ERROR or MQRC_HOST_NOT_AVAILABLE.
What I am doing is this:
string channel = "QM_TEST.SVRCONN";
string hostname = "<serverIp>";
string queueName = "QM_TEST";
string port = 1414;
props.Add(MQC.HOST_NAME_PROPERTY, hostname);
props.Add(MQC.CHANNEL_PROPERTY, channel);
props.Add(MQC.PORT_PROPERTY, port );
props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
MQQueueManager mqQueue = new MQQueueManager(queueName, props);
I have tried changing this but all failed.
I think that my problem is the server configurations..
can you point me to a full guide to how to configure a server and connect to it with .net?
My problem is connecting to a REMOTE server using .net and not to a local server.
Thank you!
The problem was that the CCSID between the client and the server were different.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaf.doc%2Fcs12480_.htm
On the client side I had to put
Environment.SetEnvironmentVariable("MQCCSID", "437");
Thats why I got:
MQRC_CHANNEL_CONFIG_ERROR
I'm guessing the problem (or at least a problem) is here:
MQQueue mqQueue = new MQQueueManager(queueName, props);
This should be
queueManager = new MQQueueManager(queueManagerName, properties);
If you have installed the WebSphere MQ client to the default location, there are many sample programs under the following directory:
C:\Program Files (x86)\IBM\WebSphere MQ\tools\dotnet\samples\cs\base\
There are a number of sample programs there for various tasks. If you have the latest V7.1 client installed then you will see the following programs:
SimpleAsyncPut
SimpleClientAutoReconnectGet
SimpleClientAutoReconnectPut
SimpleGet
SimpleMessageProperties
SimplePublish
SimplePut
SimpleReadAhead
SimpleSharingConversation
SimpleSubscribe
SimpleXAGet
SimpleXAPut
There are also WCF and XMS samples.
If you need the client code, please see my response to another SO question here for links.
Update:
Here's the normal diagnostic process.
If the WMQ components were installed by relocating libraries or classes from somewhere else, perform an install using the full vendor-supplied client media. This includes troubleshooting utilities such as trace, dspmqver, etc. It also resolves any library or class mismatch issues.
Use the pre-compiled client programs to test the connection. The amqsputc, amqsgetc and amqsbcgc programs require the MQSERVER environment variable as described here. The Q program from SupportPac MA01 is a separate download but has the advantage of NOT requiring any environment variables, CCDT files or other dependencies.
If the sample programs fail, check the QMgr's error logs at [WMQ install]/qmgrs/[QMgr name]/errors/AMQERR01.LOG for messages. Also check for FDC files and errors in [WMQ install]/errors.
If no errors on the QMgr side, attempt the connection again while using a client-side trace as described here and here.
Most client problems are resolved through installation of the full WMQ client as supplied by IBM. (Conversely that implies most people are installing by grabbing DLL or JAR files.) If the problem persists, error log inspection on the QMgr and client side usually reveals the underlying cause. If these do not work then tracing usually diagnoses the remaining issues.
UPDATE 2:
Per the error messages posted at MQSeries.net, the channel has a security exit set. A security exit is external code that the channel calls out to when starting a channel. There is no way to know what the exit expects or does without having access to the code or docs of the exit. If the exit is written in-house, you'll need to talk to the programmer to figure out what it requires. If the exit is a commercial product then you will need to get the documentation for it.
Alternatively, alter the channel so that SCYEXIT is blank to disable the exit.
The data posted at MQSeries.net was as follows:
MQ9575: DCE Security: failed to get the user's login name.
EXPLANATION:
System call 192.168.50.55 to get the login name of the user running WebSphere
MQ client application process 5 failed with error value -1. This occurred in
security exit function create_cred. The exit will now attempt to open channel
using the DCE default login context.
ACTION:
If you wish to run using the DCE default login context take no action. If you
wish to run using the user's login name as the DCE security exit principal
examine the documentation for the operating system on which you are running MQ
clients and reconfigure the operating system as necessary to allow the
192.168.50.55 call to succeed.
Note that it states the call is failing in the security exit.
I was using Nugget before (http://nugget.codeplex.com/), but when I upgraded to Chrome 14, it stopped working, and that's when I found this project: http://superwebsocket.codeplex.com/.
I've read this bit here: Is superwebsocket available in asp.net by default?, and I've also built the mono version of SuperSocket. Connecting with Chrome 14, and the websocket just shows as pending in Chrome.
I see a message like this in the server side logfile:
INFO 2011-09-22 23:44:03,924 17166ms uer - WebSocket Server - Session: 1a2dc865-9d02-468e-ac7b-26f3d0b96a2a/127.0.0.1:49261
New SocketSession was accepted!
But the WebSocketServer.NewSessionConnected event never fires. I do see the WebSocketServer.SessionClosed event firing however.
Anyone have any ideas why the new session connection event never fires, and/or why Chrome never receives any response from the socket server?
Which version of SuperWebSocket are you using?
The latest source support Chrome 14, but there is no drop for it for now.
So you should download source code by yourself.
Another problem is SuperSocket, SuperSocket 1.4 SP1 which SuperWebSocket base on has no MONO assemblies in release package, so you need build it by yourself.