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.
Related
I don't mean any offense, but as I was setting up my Octoprint, a skeptical colleague of mine pointed out that it wanted to reach out to check for automatic software updates, creating broad surface area for potential attackers.
After all, the RaspberryPi is a device inside my home network, and I worry what might happen if it downloaded and ran code designed to find other vulnerable devices on my network.
I suppose I could read the open source code, but I don't know what the software delivery story is.
Planning to donate to Gina Häußge's Patreon to ask directly.
You can turn off Octoprint's auto-update feature. It is also open-source, so you can modify its code to never contact the Internet.
Quoting Gina Häußge:
As with any software that you install on your machines, there are no guarantees that it can't be abused. OctoPrint's update mechanism utilizes Github Releases via HTTPS only, and I require anyone with commit access to the repository to have two factor authentication enabled. That should make it fairly unlikely to get any rogue releases pushed via the official update mechanism. You can also just deny OctoPrint access to the internet altogether, it will run just fine. Keep in mind though that you'll need to take care of updates and plugin installs and such manually then. Speaking of plugins, you should obviously also not install anything that you find somewhere on the net. I do my best to audit plugins that get registered on the official repository, but I cannot guarantee that their authors have 2FA and such enabled for their repositories... All I can tell you is, I do my best, spend a lot of thought on security and if push comes to shove you can always read the code yourself.
I've asked this on Adobe's LR SDK forum, thought I'd ask here as well.
I want to create a plugin for Lightroom 6+ that allows two-way communication to take place between a LR plugin and an iOS app. The iOS device would be on the same local network.
What is the best method of accomplishing this? I was thinking about using LRSocket, this is the most direct method? I assume with this method the iOS app would need to act as the server and the LR plugin would be the connecting client? But, all the documentation and examples I’ve found, regarding general LRSocket usage, imply that localhost is used. This would make direct communication with an iOS device over WiFi impossible if it can only use localhost?
Any information would be appreciated.
I've just started out trying to do the same thing, albeit with an Android app, and run into the same (apparently insurmountable) issue that LrSocket.Bind only seems to be able to bind to the localhost interface.
The only way I can think to get around this is to have an intermediary port forwarder on the LR host OS that forwards traffic between localhost:port and ethernet/wifi:port
You could use ssh on a mac, I guess, and there are port-forwarding applications for Windows (ssh is allegedly coming soon). PassPort (an old application from the XP era still seems to work).
It's a bit....messy, though.
Another option would be to use LrHttp.get (and/or .post), but that's going to have to poll for information, and may be a bit laggy for some requirements.
Is it possible to access my Cisco router details like Name,Model,IP Address,Connection status etc from my iOS mobile.
I'm even ready to write small mobile app in iOS to get all router details.
Since I have just started learning in iOS, don't know if any library already exists for above task.
If my router does not work or gets hang.. I even want to try for restart of router using my mobile.
If example code exist, it will be very useful.
Like Cisco already has andriod and iOS app for same above function but dont want to use this app and want to write my own app with limited features only.
(http://www.addictivetips.com/mobile/cisco-connect-express-manage-router-settings-remotely-android-ios/)
Thanks,
Accessing network gear is best done by using SNMP. Cisco has extremely rich management/monitoring capabilities via SNMP and all of their MIBs are publicly available here.
Almost all Cisco gear supports the SNMPv2-SMI MIB (the 1.3.6.1.2.1 OID) so querying things like sysName, sysLocation, sysContact, sysDescription, sysUpTime should be very easy. This MIB even supports tables for listing all the interfaces and IP addresses and has a whole lot of other things that might be of interest to you.
If you have SNMP write access on the device then you can even make config changes and perform management functions like rebooting or bringing an interface up/down.
There are a few SNMP libraries for ObjectiveC and I think Net-SNMP is the most popular (It's not .net even though the title suggests that).
If you are new to SNMP then I suggest starting simple by querying easy objects like 1.3.6.1.2.1.1.5 (sysName) and 1.3.6.1.2.1.1.6 (sysLocation) before trying to jump into tables like 1.3.6.1.2.1.2.2 (ifTable)
Remember, you don't have to stick with the standard MIBs you can download all of the custom ones that are particular to your device which will give you incredible amounts of flexibility.
You could use a screen-scraping technique to telnet or ssh to the Cisco device and parse the "show version" output. This will give you some of the information you need. For others, like IP addresses, you can use "show ip interface brief", "show cdp neighbors" etc. as you need.
Keep security in mind: make sure that telnet/ssh credentials are adequately protected in your app's settings, and try to restrict your commands to those that do not need privileged access on the Cisco device.
Be aware that Cisco devices have a small pool of available VTYs, and every telnet/ssh access from your app will use up one VTY. So if you have for example 30 guys wanting to use the access the device simultaneously from their apps, some of those instances are not going to get access to the device.
If this is a concern, SNMP is a better and more scalable option as suggested by previous answer. Make sure that you (a) have a read-only community string configured on the device, and (b) use only the ro community string from the app.
We used the library SimplePing, but multiple challenges of our network scanner sometimes some devices were not found. ie This scanner does not work reliably.
Prompt another library or a more reliable algorithm for IOS?
Perhaps I need to write a ping using sockets:
socket(AF_INET,SOCK_DGRAM,IPPROTO_ICMP)
But what further code?
You can see the implementation of ping utility in FreeBSD source code: https://svnweb.freebsd.org/base/release/10.1.0/sbin/ping/ping.c?view=markup
Don't be afraid to read source codes of existing implementations for any platforms, because they all use the same basis, and your app will not be an exception.
Btw, you can compile C-code for your app written in Objective-C.
Update.
And here is a good explanation about how to use sockets: http://www.linuxhowtos.org/C_C++/socket.htm
Not all devices respond to ICMP PING (which is what you're using). Are there specific devices that are never discovered? If so, do they respond to the "ping" command?
If it is more erratic, then you need to start with network traces (most commonly using wireshark). You need to determine if the pinged machine received the ping, and separately whether your device received the response. You will generally want to build a small, private network for this so you can control the hardware.
Generally speaking, it is easier to initially develop this kind of code in the simulator rather than a device. Does it work more reliably in the simulator?
Are you receiving errors? Are there firewalls involved? (Firewalls often swallow ICMP without generating errors.)
You're going to need a lot more specific diagnostic information beyond "does not work reliably." You need to know exactly which pieces do and don't work. Did you send the packet? Did they receive the packet? Did they send the response? Did you receive the response? Without those basic data, it's very hard to troubleshoot networking.
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.