Paho MQTT Golang Protocol - go

I'm new on Golang and mqtt.
I'm trying to connect to a broker. It works when I'm using MQTT.fx or my terminal with mosquitos.
But in my program, I create my opts with the address & clientID and when I try to connect there is an error "Unknow protocol"
panic: Network Error : Unknown protocol
goroutine 1 [running]:
panic(0x347b20, 0xc820072fe0)
/usr/local/go/src/runtime/panic.go:481 +0x3e6
main.main()
test.go:29 +0x1cd
I checked the protocol version on MQTT.fx and it's TLSv1.2.
The Paho library support TLS protocol. I'm a bit confused
Is there someone who got the same issue ?
Cheers

I fixed it. Just forgot to precise the protocol at the beginning of the url.
The type of connection required is specified by the scheme of the connection URL set in the ClientOptions struct, for example:
tcp://iot.eclipse.org:1883 - connect to iot.eclipse.org on port 1883 using plain TCP
ws://iot.eclipse.org:1883 - connect to iot.eclipse.org on port 1883 using WebSockets
tls://iot.eclipse.org:8883 - connect to iot.eclipse.org on port 8883 using TLS (ssl:// and tcps:// are synonyms for tls://)
That works :-)

Related

GoLang gRPC client on raspberryPI (armv7l) fails to handshake TLS 1.3

I have a gRPC client written in GoLang that I'm running on raspberryPI 4 (armv7l).
When I run the client on my MacBook it connects to the server and everything is fine.
When I run the same client on RaspberryPI 4, I get an error:
transport: authentication handshake failed: tls: server selected unadvertised ALPN protocol
Looking at the standard library, I checked that this check fails:
https://github.com/golang/go/blob/346b18ee9d15410ab08dd583787c64dbed0666d2/src/crypto/tls/handshake_client_tls13.go#L399
Function checkALPN is defined here: https://github.com/golang/go/blob/346b18ee9d15410ab08dd583787c64dbed0666d2/src/crypto/tls/handshake_client.go#L752
I printed clientProtos []string, serverProto string and it turns out that when code is run on MacBook, clientProtos contains h2 (which stands for HTTP2) and serverProto is h2 which is fine, they match and the connection gets established according to protocol.
When the same code is run on RaspberryPI, clientProtos is http/1.1 and server proto is h2 (gRPC connection can be established only over HTTP2) so there's a mismatch so the client fails to connect and says "server selected unadvertised ALPN protocol" which makes total sense. Any hints on how to proceed? Is there a reason why the client on RaspberryPI doesn't want to use HTTP2? Or maybe I have to set it somewhere? Or install something? Not sure how to proceed here and Google doesn't help. I also tried compiling client code with GoLang 1.16 but got the same error

Mosquitto Broker service refuses to start on websockets

I am trying to start my Eclipse Mosquitto broker service for listening to websockets adding:
listener 8083
protocol websockets
at the mosquitto.conf
If I only use listener 8083, the service starts but when protocol websockets is added, the service stops and refuses to start.
The error I get if I run:
mosquitto -v -c mosquitto.conf
is: 1588309602: Error: Unable to start any listening sockets, exiting.
The full output is:
1588309602: mosquitto version 1.6.9 starting
1588309602: Config loaded from mosquitto.conf.
1588309602: Opening websockets listen socket on port 8083.
1588309602: Error: Unable to start any listening sockets, exiting.
I am under Windows10 Pro.
Any ideas?
The answer to this:
Based on trials I can confirm that you need to mention a default port initially e.g.
port 1883
protocol mqtt
# Websockets
listener 9001
protocol websockets
if you only wish to use WebSockets for MQTT then instead of using listener 9001 you need to replace it with port 9001.
There should be atleast one default port to listen to in Mosquitto MQTT.
Verified using Mosquitto 1.6.10
I am posting an answer based on facts.
I have uninstalled version 1.6.9 and installed 1.6.7 and now the service is running using websockets...
I cannot confirm if this is an issue with 1.6.9 but this is what happened to me.
BR
According to other sources, the error lies in 1.6.10 (and perhaps others), whereby, there MUST be a standard protocol mqtt defined, otherwise websockets will not start.
Thus you can leave the standard configuration alone (port 1883) and then in the
Extra listeners section of mosquitto.conf, define the websockets listener as you like.
I believe this has been remedied in later versions, so that only websockets can be defined.
Sadly, in this case the only defense against unauthorized use of the broker over the standard mqtt socket is then the system firewall for external users. Users with ssh access can "play".
The mqtt protocol has to be enabled for the websockets to work.
As the option port (like others have mentioned) is deprecated in versions 2.x.x, you can use listener instead.
listener 1883
protocol mqtt
listener 9001
protocol websockets
And then run your mosquitto server as usual.

com.microsoft.azure .servicebus.primitives.ServiceBusException

I can't connect to my queue on azure account using java code. It seems that the problem is the network. I can to connect with my private network but not with the company network.
I have this message error:
Exception in thread "main" http://com.microsoft.azure .servicebus.primitives.ServiceBusException: Error{condition=amqp:connection:framing-error, description='connection aborted', info=null}.
Any hints?
It seems that the problem is the network. I can to connect with my private network but not with the company network.
Yes, you are right. I also find the simlar issue on the github. It seems that your company firewall restriction which blocks all traffic on ports 5671 and 5672. We could get more information from AMQP 1.0 in Azure Service Bus and Event Hubs protocol guide.
Azure Service Bus requires the use of TLS at all times. It supports connections over TCP port 5671, whereby the TCP connection is first overlaid with TLS before entering the AMQP protocol handshake, and also supports connections over TCP port 5672 whereby the server immediately offers a mandatory upgrade of connection to TLS using the AMQP-prescribed model. The AMQP WebSockets binding creates a tunnel over TCP port 443 that is then equivalent to AMQP 5671 connections.
If possible, you could ask permission to open 2 ports in your company firewall.

how to connect http server implemented by the c# socket class

I have finished http protocol via the socket class according to rfc2616 protocol, but how to connect https protocol and send data to server using the socket class?
When i connected https server https://www.example.com, I always get 404 error. The following is the socket command that to send to server https://www.example.com/
GET / HTTP/1.1 Host: www.example.com
the default always use http protocol
I found connected to https server need to use a connect command instead of the Get command and a client certificate. for example:
CONNECT login.example.com:443 HTTP/1.0
Major Version: 3
Minor Version: 1
......
I will try to use the connect command. Thanks for your replies.
==================================================
OK,i have solved my problem ,use the SLStream class.
NetworkStream networkStream=new NetWorkStream(socket)
var stream=New SslStream(networkStream)
.......
Now, will can read stream and write stream, until finished.

Is LDAP a TCP or a UDP protocol?

I have got some wireshark captures, and it shows that it is UDP. But in theory it says that it uses both TCP and UDP. So I m confused. And what is the difference b/w LDAP and CLDAP? Are they both UDP protocols?
Normally LDAP is a TCP protocol. But Microsoft uses LDAP also over UDP. See here:
http://msdn.microsoft.com/en-us/library/cc717362(v=prot.10).aspx
So it is both.
Lightweight Directory Access Protocol (LDAP)
The Lightweight Directory Access Protocol: The protocol accessing data from directory services like OpenLDAP, Microsoft Active Directory, Netscape Directory Server or Novell eDirectory.
Protocol dependencies
TCP/UDP: Typically, LDAP uses TCP or UDP (aka CLDAP) as its transport protocol. The well known TCP and UDP port for LDAP traffic is 389.
SSL/TLS: LDAP can also be tunneled through SSL/TLS encrypted connections. The well known TCP port for SSL is 636 while TLS is negotiated within a plain TCP connection on port 389.
https://wiki.wireshark.org/LDAP

Resources