I have tried using ESP-CoAP but the coapclient.ino example does not work for me. The server in this example is 129.132.15.80. Is there any other server I can use to test my code? I have also tried coap.me but this code only accepts IP addresses. Are there any alternatives to this library that are regularly maintained?
About the question for test-servers:
Many OS offers you a way to resolve a address as "coap.me" to their numeric address (e.g. unix nslookup coap.me => 134.102.218.18). The open source project Eclipse/Californium offers a sandbox as well (nslookup californium.eclipseprojects.io => 104.196.15.150). You may also try to run Californium's Plugtest Server locally (requires installed java).
In all cases, it's a good idea to get common with ip-capture tools as tcpdump or wireshark. A very first introduction may be found here
About the question for maintained c-implementations:
libcoap is a very common one. But I don't know, if there is a "out of the box" ESP 32 port available.
Related
The latest ESP-WROOM-02 support TLS1.2 over AT commands (I got this confirmed by Expressif). However I would like to use the ESP-01 unmodified to connect to an MQTT-broker, using TLS1.2. Is it possible to use the ESP01? Does it use the same firmware or codebase? I can't seem to find concrete answers.
Note that my app runs on another MCU (unavoidable). In principle I could reflash the ESP module, but that would add a step in the production process, plus yet another development environment. An advantage would be that the ESP01 firmware version would be strictly known.
I've seen that many advise to reflash the ESP with an Arduino derived firmware aka WiFiClientSecure and thus avoid working with the AT-commands (indeed I found NO library to specifically (and reliably) work with them).
Any advice greatly appreciated.
If you're concerned about security, then ESP8266 family modules (such as the ESP-01, ESP-WROOM-02, D1, NodeMCU) are likely not a practical choice.
They don't provide a mechanism for encrypting credentials on the device or a way to ensure that no one has altered the code that's running, and you end up in a situation like this one: https://thehackernews.com/2016/01/doorbell-hacking-wifi-pasword.html
However, the ESP-32 does provide that. It also allows you to make a secure MQTT connection. While it's more expensive than the ESP-01, it's still pretty affordable (about $6 on AliExpress).
The doorbell hack example is just stupid.
Why didn't they add a password for the Access Point connection.
I've searched this subject in stackoverflow and found out that a telnet library would help, and I found a telnet lib here: C# Telnet Library
but I don't know how I can use a telnet library to open a port in my router. I'm using an AT&T 2wire router. Any hints on how I can do this?
You can't. The 2wire router is an island unto itself, if it decides to block a port nothing external can (or should) be able to change that. You are on the wrong track, and would need to restate your goals in order to get a useful answer.
UPnP and other "Hole Punching" techniques do exist: but you'll be in a world of hurt if you try to reply on them for any widespread deployment.
Perhaps you meant to open a connection to a remote server and then establish two way communication. That is easy... and how other games and tools get the job done.
Technically speaking you should not be able to. You shouldn't have outside programatic access to a router to open a port if it's blocked.
If what you mean is opening a port for communication (that is not blocked) then you can simply create Sockets with the address and port (ex. localhost 7777) to establish inter process communication or simply communication with another server.
As I mentioned in a comment below there are ports that are available for use (in C# this can be easily tested, a quick google search will find you many snippets of code for testing if a port is open). A simple approach is to simply start at port 1024 (I believe this is the correct lower bound for ports that should be used by applications, someone correct me if I'm wrong) and just start counting up until you find a port that is available, if you find you've reached some upper limit you can simply report that a connection cannot be made. I hope this clears up a little more and if I have time I will try to find some code I have for this and edit it in but honestly a quick search can net you similar code for checking ports in C#.
I have a Delphi application that reads/writes to a COM port connected to a large hardware device, so I don't usually have the hardware available during development. That said, the communication protocol is fairly simple, so I can generally do the development and have someone onsite test it, and it usually works. Occasionally I run into a harder problem, though. To solve this, I'd like to setup a virtual COM port where one side of the COM port is my application and the other side is a very simple COM port debug console (similar to the old modem terminal programs), where ASCII commands my app sends are logged onscreen and I can type in some ASCII command to send back to my application to simulate the hardware device. I've been unable to find any tools that provide a virtual/software COM port and a console/terminal to debug with. Does anyone have software suggestions and steps to set something like this up?
The software/virtual COM port and terminal need to support Windows 7 64-bit (or Vista 32 if necessary).
I'm doing something similar with paired virtual COM ports created by
http://com0com.sourceforge.net/
I'm using Advanced Virtual COM Port and I'm quite happy with it. Not free, but works like a charm - even with Win7-x64.
Can't you just insert a redirector at the lowest level of your application which will pop up a console instead of writing data to COM? Should not take long.
I can't vouch for it, but sounds like something like this is what you're looking for. http://www.windows7download.com/win7-free-virtual-serial-ports-emulator/yarqmowu.html
I have used Eterlogic's Virtual Serial Ports Emulator successfully for exactly this on a laptop with no serial ports. It's a bit easier to set up than Com0Com, which I have also used. It's also useful for serial port spying if you need to reverse engineer any communications
The 32-bit version is free, the 64-bit version is currently $25. Try it out on Vista32 to see if it does what you need.
I use Com0Com for this purpose, but I don't know whether it works with anything more recent than Windows XP.
I've just installed pfSense (a FreeBSD distro) and I'm having problems with my Ethernet adapters - I seem to be able to get it into a state where I cannot ping any machine despite the ARP tables etc... all being correct (On the machine I'm pinging I can see the packets arrive and the response sent in Wireshark, but the remote machine gets nothing)
Having an interest and limited knowedge in OS development I kind of want to have a go at debugging this, but in many ways I'm not really sure where to start:
How do I go about getting the source code for the drivers I'm using? Will they be part of the FreeBSD source code, or is there going to be some external project? (or are the drivers I'm using likely to be the proprietry ones released by Realtek, and therefor not have source code)
For that matter, how do I identify what drivers I'm currently using?
Finally, are there any good resources on how to debug Kernel-level / device drivers?
(I appologise if I'm asking silly questions or if I seem overly optimistic about what I'm hoping to achieve by debugging this, but although I lack experience in this area I consider myself to be a smart guy and I've gotta start somewhere!)
I really doubt your problem is in the device drivers or other kernel code. Check the PF rules - you most probably just dropping all ICMP packets out right.
Is it possible to emulate incoming messages using Indy (if it's of any importance: I'm using Indy 10 and Delphi 2009)? I want to be able to create these messages locally and I want Indy to believe that they come from specific clients in the network. All the internal Indy handling (choice of the thread in which the message is received and stuff like that) should be exactly the same as if the message would have arrived over the network.
Any ideas on that? Thanks in advance for any tips.
What you want to do has nothing to do with Indy, as you would need to do this on a much lower level. The easiest way to make Indy believe that messages come from a specific client is to inject properly prepared packets into the network stack. Read up on TCP Packet Injection on Google or Wikipedia. EtterCap is one such tool that allows to inject packets into established connections. However, this is definitely going into gray areas, as some of the tools are illegal in some countries.
Anyway, all of this is IMHO much too complicated. I don't know what exactly you want to do, but a specially prepared client or server is a much better tool to emulate certain behaviour while developing server or client applications. You can run them locally, or if you need to have different IP addresses or subnets you can do a lot with virtual machines.
Indy doesn't have any built-in mechanisms for this but thinking off the top of my head I would recommend building a small test application (or a suite) that runs locally on your development machine and connects to your Indy server application to replay messages.
It should be irrelevant to your Indy server applications if a TCP connection is made either locally or from a remote host as the mechanisms by which a server thread is created and a command processed is identical to both scenarios.
My last gig involved using Indy and all our testing was done with a similar Resender type application that would load local message files and send these to the Indy server app.
HTH and good luck!
One thing you can do would be to create virtual machines to run your test clients, that way they will not be seen as "local machine", and its fairly simple to create a complex network with VMS -- provided you have enough memory and disk space. The other advantage of testing with VM's is you can eliminate the development environment completely when its time to focus on deployment. Amazing how much time that saves alone.
VirtualPC is a free download from Microsoft and works fairly well. VMWare has another option, but costs a little more to get started. For development purposes, I prefer the desktop versions but the server versions also work well. You will still need to have a license to install the virtual OS. MSDN membership is probably the cheapest way to go, and allows you to build test environments for other flavors of the OS.
Indy has abstract stack mechanism for crossplatform support (IDStack.pas) I think u can hack the stack for windows (IdStackWindows.pas). It is a class. U can even consider to derivate it and override some functions to do the hack.