In my setup I have a mqtt.js client which publishes to a mosquitto broker (qos: 2). Now I have the problem that some messages are silently dropped by mosquitto because the client is unauthorized to publish to that specific topic. In this stackoverflow question it is said that it is not possible to recognize that as client because that would be a security issue. However it seems that mosquitto sends a "not-authorized" reason code in the PUBREC message. Wouldn't it be possible for the client to still get the info that it can not publish to that topic? What am I getting wrong?
You might be able to parse it out of the PUBREC packet yourself by registering an packetreceive callback
client.on('packetreceive', function(packet){
})
Related
I had been developed a telegram bot using Telegram.Bot.
I tried to rework with the bot, First I created bot using BotFather and got token.
I set webhook server api address in telegram api. But when I check webhookinfo it returns this error
https://api.telegram.org/botToken/getWebhookinfo
respone:
"last_error_date":1585419712,"last_error_message":"Connection timed out"
I checked it need TLS12 to have secure connection using
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
But It's not getting updates in my server and show time out error.
I tried posting using postman and ngrok to run on my iisexpress and I'm getting data and can sending messages to bot in my localhost.
But In hosting it's not working, whats wrong with new Telegram.Bot library or telegram server?
update
I checked with postman my hosting url, post man also cant connect to that url. what can be wrong with my codes?
This is response when i'm call update receiving URL in my hosting:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.10.34.35:443
I got problem, the certificate which we use should be valid one, not free.
For more information please study this link:
https://core.telegram.org/bots/webhooks
I read the MQTT-SN spec and I am unsure if it also can support the request-response pattern. Does anyone know ?
Trying to implement something like this...
http://www.steves-internet-guide.com/mqttv5-request-response/
Where the MQTT v5 publish command can specify the response-topic as seen in the MQTT v5 spec here:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
4.10.1 Basic Request Response (non-normative)
Request/Response interaction proceeds as follows:
An MQTT Client (the Requester) publishes a Request Message to a topic. A Request Message is an >Application Message with a Response Topic.
Another MQTT Client (the Responder) has subscribed to a Topic Filter which matches the Topic Name >used when the Request Message was published. As a result, it receives the Request Message. There could >be multiple Responders subscribed to this Topic Name or there could be none.
The Responder takes the appropriate action based on the Request Message, and then publishes a >Response Message to the Topic Name in the Response Topic property that was carried in the Request >Message.
In typical usage the Requester has subscribed to the Response Topic and thereby receives the >Response Message. However, some other Client might be subscribed to the Response Topic in which case the >Response Message will also be received and processed by that Client. As with the Request Message, the >topic on which the Response Message is sent could be subscribed to by multiple Clients, or by none.
The MQTT-SN spec is here
http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf
It is just written differently and I cannot tell if this feature is supported.
Ultimately, for certain messages, I need to have a response which cannot be left to the pub/sub fire and forget pattern. MQTT-SN v1.2 is required for the connection since it goes over BLE and cannot support TCP/IP and so no regular MQTT v5.
I suppose I could just make up a "Response Topic" field to put into the payload of the request which the receiving client can process and respond to. But, does the MQTT-SN v1.2 spec already support it ?
No, MQTT-SN v1.2 does not include the features added to MQTT in v5.
As you said, there is nothing to stop you including your own response topic field in the message payload.
I'm having issue with https://graph.microsoft.com/v1.0/users/<userId>/sendMail.
I get 202 Accepted as response, however when I browsed to the user's mailbox above, I'm receiving delivery failure notification as below:
Delivery has failed to these recipients or groups:
<username>#outlook.com
Your message wasn't delivered because the recipient's email provider rejected it.
Remote Server returned '550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP. For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653 AS(7171) [SYBPR01MB4428.ausprd01.prod.outlook.com]'
When I logon to Outlook and send email to <username>#outlook.com from <userId>'s Outlook, the email was sent successfully.
Anyone know what's happening here?
I've tried to add a SMTP connector, but doesn't fixed the problem. When SMTP connector send an email to test Outbound Email, it works fine as I can receive at <_username_>#outlook.com.
If you follow the link provided, it explains what is happening
5.7.708 Access denied, traffic not accepted from this IP
The majority of traffic from this tenant has been detected as suspicious and has resulted in a ban on sending ability for the tenant.
Ensure that any compromises or open relays have been resolved, and then contact support through your regular channel.
For more information, see Fix email delivery issues for error codes 5.7.700 through 5.7.750 in Exchange Online.
I am running Mosquitto and nodered in the same raspberry, I send succesfully messages to a my MQTT Server and also have created an input node that connects succesfully. I am now trying to get, from the message received, the clientId info. Is there any way to get it?
Thanks
The MQTT protocol does not include any information about who published a message when it gets sent to a subscriber.
You would need to include this information in the topic string or payload the publisher sends.
I am having an intermittent issue with Twilio. Once out of every 50 or 75 calls, we get a call that fails, and when I check the logs, it states that it is error 11200, and it gives a Bad Gateway 502 message "An upstream server received an invalid response".
I've taken a look at Twilio's suggestions regarding this error (found at https://www.twilio.com/docs/errors/11200). They list a bunch of probable causes for a bad gateway error:
1) Web server returned a 4xx or 5xx HTTP response to Twilio - as far as I can see in the logs, the web server is returning a 200 HTTP response to Twilio.
2) Misconfigured Web Server - We have checked the configuration of our web server, and believe it to be correct.
3) Network disruptions between Twilio and your web server - we have tested the ping response time, and the packet loss between www.twilio.com and our server. The ping time is < 100ms, and there seems to be no packet loss when testing with ping -n 100 www.twilio.com
4) No Content-Type header attached to response - we set our Content-Type to application/xml.
5) Content-Type doesn't match actual content - We set our Content-Type to application/xml and are using the TwiML language to send our responses back.
We have also checked all elements in Twilio's Possible Solutions section for this error.
A bit about what we are doing:
API Version: 2008-08-01
We only make outgoing calls.
We use TwiML to send a Say command, followed by a Gather. It is during the Gather that we get our intermittent error. The user will press a key, which gets sent back to us. Depending on which key is pressed, we then send another Say to Twilio - for example "You pressed 1. This offer has been accepted. Thank you." or "You pressed 2. This offer has been declined. Thank you."
I'm not ruling out that it's something at our end that is causing the issue, but we don't really know what to check next. The web server appears to be sending a 200 response back, but Twilio seems to be receiving a 502.
Does anybody have any suggestions that might help us out? Could it be a problem with the API we are using? Should we be upgrading to 2010-04-01?
Thank you in advance!