I have created a test account to IOThub and pulled down the azure-iot-sdks git archive to test with.
I have added my connection string to both the iothub_client_sample_http and iothub_client_sample_mqtt .c files.
When I run the iothub_client_sample_http I see a couple of network packets sent and acked before I get a segmentation violation in pthread_mutex_lock called from PR_lock. I will track this down and fix it.
More importantly, I want to use the MQTT protocol. When I execute the iothub_client_sample_mqtt app I get a timeout in the connect code. I have looked at the packets with wire shark and what I see is:
TCP 74 33226 > secure-mqtt [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=81898578 TSecr=0 WS=128
Then two more packets going out the same with retransmission. I never see any reply packets.
Is there something I need to enable at the IOThub to allow using MQTT?
I actually want to use mosquitto in the product and I get the same scenario from my code.
Thanks for any help.
You can also use MQTT over WebSockets which uses 443 port instead of 8883.
See more details from https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-mqtt-support
Thanks for the answer. It turns out the company was filtering all packets to port 8883 and that was my issue.
MQTT has some particular advantages over other protocols to the hub. As it becomes more popular IT organizations will need to change this type of thing.
Thanks again.
Related
I'm using an STM32 as the main microcontroller and ESP8266-12F as the Wi-Fi module. These 2 are connected to each other via serial port and communicate with each other by AT-COMMANDs. To program the STM32, I'm using Keil IDE and I'm not changing the firmware of the ESP8266 at all.
I have a secure MQTT with a CA.CRT file to which I want to connect.
1- What steps should I take to establish a connection between MQTT broker and ESP8266?
2- How should I add CA.CRT file to ESP8266?
3- What are the AT-COMMANDs which I need to use?
4- Can you provide a pseudo code to clarify the answer?
After reading #hcheung comment and his proposed document, I found out that theoretically, I can solve this problem by the method mentioned on the 44th page of ESP8266 AT Command Set and ESP SSL user manual.
In the coming week, I will check this and update this answer.
I am trying to debug an LWM2M protocol issue. I need to know what messages are transferred between the COAP server and the COAP client. As the traffic is encrypted using DTLS, I need to give the pre-shared key in wireshark to see the payload. Wireshark is successfully decrypting the payload, but I am not able to see the underlying COAP protocol messages. I am seeing just the raw data("Application data"):
But when I try sniffing unencrypted COAP traffic on a dummy setup, I could see the COAP messages properly:
How can I view the COAP protocol traffic using wireshark when it is encrypted?
The problem is that you're using a non-standard port number for COAPS instead of the IANA-registered port of 5684, and the Wireshark COAP dissector's proto_reg_handoff_coap() function only registers to the DTLS dissector with that fixed, non-configurable port (DEFAULT_COAPS_PORT). There are some possible ways to fix this and/or work-around it.
If possible, change your application to use the standard port, 5684.
Modify the Wireshark COAP dissector to also register to the DTLS dissector with your desired port, or better yet to allow the port to be configurable, perhaps even with a port range preference to allow multiple ports to be registered. You can reference the Wireshark Developer's Guide for information about compiling and developing for Wireshark on your particular platform.
Submit a Wireshark Issue, asking for an enhancement to the COAP dissector to allow the DTLS-registered port to be configurable. Again, a range preference would probably be even better, as it would allow more than just 1 port to be registered.
Assuming the first option isn't possible and the other options would take longer and not solve the immediate problem of dissecting the payload as COAP for your existing capture file, you could use a program such as TraceWrangler (or other such Capture file editors and/or anonymizers tools) to rewrite the UDP port value of 57845 to 5684 for all packets. That should allow the payload to be passed to the COAP dissector without requiring any other changes. If you do use TraceWrangler, then the basic steps would be:
Add Files: Choose your file, i.e., file.pcapng.
Taskname: Anonymize Files.
Payload: Deselect "Remove all unknown layers..." as you want to keep everything.
PCAPng: Action=Passthrough, as there's no need to replace original comments here.
Layer 4, UDP: Action=Replace. Select "Replace UDP ports by list", then choose Add. Enter 57845 for the Original port number and 5684 for the Replacement port number, then click Add.
Select Okay.
Select Run.
When the Status indicates, "Task complete", you should be able to open the newly created packet capture file, named file_anon.pcapng, in Wireshark and Wireshark should now recognize the payload as COAP.
DISCLAIMER: I have not tested this myself, but it should work.
We have email validation tool which tell, is valid or invalid by checking MX record ect.
It is working fine in my old server. Same build which i have deployed in another server Windows 2012, is not working, may be fire wall is blocking ?
I have opened port 25 in both InBound and OutBound
What i need to do ?
In that tool, which query MxRecords DnsQuery
Your issue is that you've confused the port for SMTP (25) with the port for DNS (53). Open 53 and you should find that your queries work. Note that you will need to open it for both TCP and UDP; packets at or below 512 bytes use UDP, above that use TCP.
More information can be found on Wikipedia.
I spent the last two days reading each StackOverflow questions and answers (and googling of course) about Indy TCP and UDP protocol in order to decide which one should I use in my communication method between my User Application and my Windows Service.
From what I saw so far, UDP is the easiest and the only one I managed to work to receive broadcast messages from TidUDPClient (I did not testes the response back yet). And I also noticed that TCP is a bit more complicated with it's thread loop.
But since everywhere I am told UDP is not reliable, UDP is not reliable... I begin to wonder if it's not better to use TCP anyway.
My User Application will be running on many machines, and the Service will be running in one of them, sharing one IP with a Client, or in a dedicated machine, depending on my client's funds. So, should I really be worried about UDP data loss possibilities?
I need broadcast capabilities so my server advises all clients at once about Application updates, and of course, if my the Client Application does not know in which IP the Service/Server is, it will send a broadcast call to be told where the server is. Is that applicable to TCP?
The messages I am sending are requests for users access confirmation, users privileges, and application executable file updates, since the main application can't update itself.
Those messages are encrypted like below, and they might bet bigger sometimes.
e86c6234bf117b97d6d4a0c5c317bbc75a3282dfd34b95446fc6e26d46239327f2f1db352b2f796e95dccd9f99403adf5eda7ba8
I decided to use them both!
Simple use case:
In order to communicate with TCP prococol you have to establish a connection which you can have only if you know IP and Port on both ends.
If you do not have that information when you load your Application, then you use the UDP to Broadcast your IP address and your intention to find the/a Server. You may try about 5 times before you raise the user an error telling that you did not find the Server or that the Server is down.
Sending that message in UDP will (one time or other) reach the UDP ear of the Server, which will now know the IP from the lonely Client's IP and will now begin a proper connection via TCP to be read talk about the critical messages of the Application.
What do you think of that approach?
I have a packet capture and I'm trying to find out which program a download was made with, where would I go in the packet to find this information?
Thanks all!
Instead of looking for answers within the packet, you may want to look at which port the download was done through. That could give you more information, and faster
I assume you know the destination ip address from where the file is downloaded. If it's something that you can catch while it's happening or you can trigger it then you could use netstat to determine the PID of the program that is handling that socket after filtering the netstat output based on the destination ip address.
Then you could use ps on Linux or TaskManager on Windows to know which program has that PID.
On windows: How to determine which program uses or blocks specific transmission control protocol ports in Windows
Alternative if the packet capture it's all you got and it's not a recurring event then if the download was done via HTTP you could check the headers of the HTTP request for info about the client in the User-Agent header.
Hope it helps.