Im working on getting node-xmpp working with a jabber server we have in house here. I was able to get it working with talk.google.com just fine, and i can connect to our internal server with adium or ichat just fine.
Node v0.6.14
CentOS 6.2 / 2.6.32
node-xmpp 0.3.2
OpenSSL 1.0.0
connect code
var j = new xmpp.Client({
jid : 'user#domain',
password : 'pass',
host : 'chat.domain'
});
After tracing through the code, it seems it gets stuck right after it tries to upgrade the connection to a secure connection. This occurs in starttls.js in the starttls function.
The pair.on('secure') event is never called, and even after i print out pair after a settimeout, its still not appearing to be authorized. At this point i dont see any data in or out.
After a long time sitting there (several minites) it prints out an error that looks like this
throw arguments[1]; // Unhandled 'error' event
^
Error: 139644497663968:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:674:
at CleartextStream._pusher (tls.js:508:24)
at CleartextStream._push (tls.js:334:25)
at SecurePair.cycle (tls.js:734:20)
at EncryptedStream.write (tls.js:130:13)
at Socket.ondata (stream.js:38:26)
at Socket.emit (events.js:67:17)
at TCP.onread (net.js:367:14)
The server is using a self signed cert if that matters.
Any ideas?
Thanks!
This looks like you're sending a TLS handshake when the server isn't expecting it, so the server isn't sending its handshake back.
One possibility is that you're talking old-style TLS (handshake-first) to a server that implements start-TLS. In your real code, are you setting the legacySSL parameter? Are you sure you're talking to an XMPP server on the target box?
A wireshark trace would give us the data to be able to tell for sure.
I was experiencing the same issue: connection hangs while trying to perform a TLS handshake with one particular Openfire XMPP server installation (though others worked fine).
After nearly losing my mind, I ended up modifying starttls.js that ships with node-xmpp to use tls.connect() and forcing SSLv3 and to my surprise it worked.
Gist here: https://gist.github.com/jamescoletti/6591173
Hope this is useful to someone.
Related
response=421 4.7.0 Try again later, closing connection. (EHLO) vj23-20020a170907131700b0078db51bb303sm9553ejb.86 - gsmtp: 421 4.7.0 Try again later, closing connection. (EHLO) vj23-20020a170907131700b0078db51bb303sm9553ejb.86 - gsmtp Error: Server terminates connection. response=421 4.7.0 Try again later, closing connection. (EHLO) vj23-20020a170907131700b0078db51bb303sm9553ejb.86 - gsmtp: 421 4.7.0 Try again later, closing connection. (EHLO) vj23-20020a170907131700b0078db51bb303sm9553ejb.86 - gsmtp
I found a solution I hope it will help you I replaced nodemailer Smtp by emailjs and this will solve the problem.
https://www.npmjs.com/package/emailjs
I believe Nodemailer uses the computer's hostname in place of the name property when creating a transport. This can cause issues with some email relays such as Gmail. To fix this you can explicitly set the name property in the SMTP transport options to an arbitrary string.
Background
I am trying to investigate and solve problems with a containerized NodeJS web service app that communicates with Avalanche Test Network (https://api.avax-test.network/ext/bc/C/rpc) in order to Mint NFTs.
//...
provider = new HDWalletProvider({
privateKeys: [walletPrivateKey],
providerOrUrl: "https://api.avax-test.network/ext/bc/C/rpc",
pollingInterval: 4000,
});
const myContract = Contract(Contract_NFT);
myContract.setProvider(provider);
const _instance = await myContract.at(process.env.CONTRACT_NFT_ADDRESS);
_instance.mint(provider.getAddress(), mintURL, { from: provider.getAddress() })
//...
Note: I am not the developer of app.
Issue
After starting the container, first request completes successfully. However subsequent requests fail with code: -32603 message: 'ETIMEDOUT' error
at new NodeError (node:internal/errors:387:5)
at Web3ProviderEngine.emit (node:events:502:17)
at /app/node_modules/web3-provider-engine/index.js:54:14
at afterRequest (/app/node_modules/web3-provider-engine/index.js:148:21)
at /app/node_modules/web3-provider-engine/index.js:174:21
at /app/node_modules/web3-provider-engine/index.js:232:9
at /app/node_modules/async/internal/once.js:12:16
at replenish (/app/node_modules/async/internal/eachOfLimit.js:61:25)
at /app/node_modules/async/internal/eachOfLimit.js:71:9
at eachLimit (/app/node_modules/async/eachLimit.js:43:36)
at /app/node_modules/async/internal/doLimit.js:9:16
at end (/app/node_modules/web3-provider-engine/index.js:211:5)
at Request._callback (/app/node_modules/web3-provider-engine/subproviders/rpc.js:36:21)
at self.callback (/app/node_modules/request/request.js:185:22)
at Request.emit (node:events:513:28)
at Timeout.<anonymous> (/app/node_modules/request/request.js:851:16)
Error: PollingBlockTracker - encountered an error while attempting to update latest block:
undefined
at PollingBlockTracker._performSync (/app/node_modules/eth-block-tracker/src/polling.js:51:24)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
When the app is used outside a container and directly on server OS, all requests successfully complete.
What I have tried
I tried searching the internet forums and boards. Similar issue is mentioned in some posts but suggested solution is to tweak Timeout/Interval values which did not help with my issue and still got the error.
I tried using the same NodeJS and NPM versions installed on server OS. Also tried using different versions of NodeJS( 14.XX, 16.XX). Still got the same error.
Also I have tried changing and configuring Docker network( different type of network driver, different IPAM config, passing extra hosts etc.). Still got the same error.
I have confirmed that mentioned URL is accessible from inside container using ping, nc and dig tools. Also have confirmed that successful HTTPS connection is being established.
Questions
What is causing this behavior?
What I can do to reliably use this app inside container?
Have I missed something?
I have a basic Pulsar app, and when I try to connect to Pulsar, I get this exception:
2021-03-10 14:38:26.107 WARN 7 --- [r-client-io-1-1]
o.a.pulsar.client.impl.ConnectionPool : Failed to open connection
to my-pulsar-server-ms-tls.domain.com:6651 :
io.netty.channel.ConnectTimeoutException: connection timed out:
my-pulsar-server-ms-tls.domain.com/10.80.13.38:6651 2021-03-10
14:38:26.212 WARN 7 --- [al-listener-3-1]
o.a.pulsar.client.impl.PulsarClientImpl : [topic:
persistent://myTenant/myNamespace/myTopic]
Could not get connection while getPartitionedTopicMetadata -- Will try
again in 100 ms
My Pulsar client is pretty basic:
PulsarClient.builder()
.serviceUrl(serviceUrl)
.authentication(AuthenticationFactory.token(authToken))
.tlsTrustCertsFilePath(serverCertificateFilePath.toString())
.enableTlsHostnameVerification(false)
.allowTlsInsecureConnection(false)
.build();
The producer is also pretty basic and looks like this:
pulsarClient.newProducer(Schema.STRING)
.topic(topic)
.create();
I've verified that the token and TLS cert are correct. I've also tried connecting a consumer from this same environment and got a similar exception, and I know that others with the same code are able to connect to the same Pulsar cluster from other environments. What is the issue?
Your connection is getting blocked by a firewall or network issue.
Verify that you can establish a connection to your endpoint my-pulsar-server-ms-tls.domain.com:6651 from your environment.
If you're able to run a network packet dump (like tcpdump), that should make it obvious if you're not able to establish a connection.
You can also try running curl my-pulsar-server-ms-tls.domain.com:6651, and if you get back some html, that means you were able to reach the server. However, if you get Could not resolve host, then you were blocked by the network configuration (such as a missing route) or firewall.
I'm writing a script to get some sensor-data using MQTT, transform the incoming value is a specific way and forward it to a cloud which uses an encrypted communication.
The script runs on RaspberryPi 3 (Raspbian) where Mosquitto runs as MQTT-broker ( The sensors send the data to this broker)
So far I get the information from the the sensors and I can transform the content like desired.
The problem is when I try to connect to the remote broker, I got following error-message
Error: error:0906D06C:PEM routines:PEM_read_bio:no start line
at Error (native)
at Object.createSecureContext (_tls_common.js:67:17)
at Object.TLSSocket._init.ssl.onclienthello.ssl.oncertcb.exports.connect (_tls_wrap.js:1015:46)
at Object.buildBuilder (/home/pi/node_modules/mqtt/lib/connect/tls.js:13:20)
at MqttClient.wrapper [as streamBuilder] (/home/pi/node_modules/mqtt/lib/connect/index.js:135:36)
at MqttClient._setupStream (/home/pi/node_modules/mqtt/lib/client.js:246:22)
at new MqttClient (/home/pi/node_modules/mqtt/lib/client.js:227:8)
at Object.connect (/home/pi/node_modules/mqtt/lib/connect/index.js:138:10)
at Object.<anonymous> (/home/pi/GATT_server/MQTT_module.js:3:25)
I have tried to configure Mosquitto as MQTT-bridge to use the config-file and it looks like it'd work (There are no error messages when the service is restarted).
The problem when I use Mosquitto as a bridge the script can't subscribe to the topics published by the sensors.
I'm not familiar with those certificates but from reading the doc of the file 'client-options.cs' I wrote following lines:
var mqtt = require('mqtt')
var client = mqtt.connect('mqtt://localhost', 'port:1883');
var remoteBroker = mqtt.connect('mqtts://xxx.xxx.io',
{port:8883,
protocol:'ssl',
username:'username',
password:'123password123',
cert:'/etc/mosquitto/certs/ca.pem'} );
/*....
.... many lines later
....*/
remoteBroker.publish(topicToUseOnRemoteMqttBroker, PayloadToForward);
Am I doing it right? Or did I miss something?
If the certificate is OK for the Mosquitto-Bridge it should be OK for the remote broker, too. - Is that right?
If you have additional links/papers about this topic - I like to learn ;P
Google gave me so many information - I don't know where to start :(
The entry for the cert should not be the path to the certificate file, but the actual cert it's self. You need to read the file in and pass that.
Somethings like this:
var remoteBroker = mqtt.connect('mqtts://xxx.xxx.io',
{port:8883,
protocol: 'ssl',
username: 'username',
password: '123password123',
cert: fs.readFileSync('/etc/mosquitto/certs/ca.pem')} );
I'm using socket.io with easyrtc to have a p2p video chat. Working example at https://github.com/merictaze/enlargify with following package versions
"express": "^4.15.2",
"easyrtc": "1.0.x", // easyrtc#1.0.15
"socket.io": "^1.4.5"
The easyrtc logic used is at https://github.com/merictaze/enlargify/blob/master/public/resources/js/app.js
However, if i bump up easyrtc version to 1.1 The code stops working. I've even tried the beta branch.
"express": "^4.15.2",
"easyrtc": "priologic/easyrtc#beta",
"socket.io": "^1.4.5"
I know this isn't helping much, so on further investigation i found out that it fails at this call
easyrtc.call(self.partnerId, successCB, failureCB, acceptedCB);
The Error code from failureCB is
MSG_REJECT_TARGET_EASYRTCID
On the server side the log shows
2017-12-07T07:02:40.477Z - debug - EasyRTC: [enlargify_app][fNhseVCWzi8XXhn5] EasyRTC command received with msgType [offer] undefined
2017-12-07T07:02:40.478Z - warning - EasyRTC: Attempt to request non-existent connection key: '0xv7UpIAlVeAzEedAAAA' undefined
2017-12-07T07:02:40.479Z - warning - EasyRTC: [enlargify_app][fNhseVCWzi8XXhn5] Could not send WebRTC signal to client [0xv7UpIAlVeAzEedAAAA]. They may no longer be online. undefined
However, reverting the easyrtc version back in package.json works as it does on the demo here http://enlargify.herokuapp.com/
I want to update the easyrtc version because of the safari support in the beta branch. I found the demos working smoothly.
ps. I did update the socket.io version and updated the deprecated calls e.g
partnerSocket = io.sockets.socket(socket.partnerId);
partnerSocket.emit("disconnect_partner", socket.id);
to
io.to(socket.partnerId).emit("disconnect_partner", socket.id);
Further investigations show that the socket.id generated on the client side is different from the one on server. That's why the two peers are unable to connect.
Any idea how i can get success function of easyrtc.connect to return the correct socketID?
Answering my own question here so if someone else stumbles upon this, they won't waste hours like i did.
The reason for the difference in Ids on client and server is because prior to version of easyrtc#1.0.15, easyrtc relied on SocketIO's ID and used it as the EASYRTCID as well. This meant that both socket.id and easyrtcid can be referenced interchangeably. That's why it worked in old versions.
As explained at https://github.com/priologic/easyrtc/issues/185 they changed the functionality and made EASYRTCID based on a new pattern. As signaling server (socketIO) would emit to socket.id while easyrtc when initiating the calls would use easyrtcid. Hence business logic is needed to pass easyrtcids between peers via socket in order to make easryrtc call.
In addition to above we also need to tell the easyrtc object to use the socket instance of the signaling server. I followed this example https://demo.easyrtc.com/demos/demo_instant_messaging_selfconnect.html