TASK: I have a task: I need to understand with the help of static network analysis methods which model I am dealing with. I need to try to find out the firmware version, manufacturer, device type. I am interested in solving my problem within the framework of the most popular Internet of Things protocols: LoRaWAN, 6LoRaWAN, Zigbee, Z-Wave.
I found a study Detecting IoT Devices and How They Put Large Heterogeneous Networks at Security Risk that uses ping, nslookup and the web interface of the applications themselves. They had a whole huge network of real smart devices at their disposal. I do not have the opportunity to assemble my experimental stand from real devices. What should I do in this situation?
PROBLEM: How can I emulate the operation of devices, so that later I can communicate with them over the network as with real ones.
Related
These are many articles on internet, researches on the point that their is need to make IoT communication more secure. What are the difference in IoT communication and conventional communication, that there arise need of so much extra research, emergence of new communication protocols etc.. I may be missing some crucial point here.
IoT devices are cheap, small and have limited processing power. Therefore, their software typically doesn't contain the security features of desktop operating systems (implementing an SSL protocol is just not possible on many devices, because they don't have enough capacity). Despite that, IoT devices such as smartwatches transmit highly sensitive information, such as the whereabouts of its wearer and things like his night-time activities...
Additionally, many cheap IoT devices come with one preinstalled, unchangeable software. Or software that never gets any updates after the product is launched. This makes it easy for hackers to abuse these devices once a security leak is found in the code.
I’m creating an IOT device with some unusual needs when compared with typical home automation. I wanted to ask if anyone knew of a mesh protocol (Zigbee, Thread, BLE Mesh), that might be able to achieve this user experience:
When someone turns on their device, it looks to connect to a mesh network, comprised of other devices they have previously “friended”.
If no network is found, it creates its own mesh network, available for other “friended” devices to connect to, when those devices turn on.
If the device creates its own mesh network (as in behaviour above), but no one connects to it – and then the device finds a different network with more than one friend on it, the device should kill its own network in favour of connecting to the other.
I’m expecting that there will not be a “master” node who has “friended” every possible device that wants to join the network – I’d like the possibility for “friends” to bring their “friends”, to also join the network.
If a partition in the network occurs (this is very likely to occur in my use case), the network should automatically re-form when the devices are close to each other again.
All devices are expected to be identical in function, size, software – so BLE Mesh is probably not suitable given it needs a “Provisioner”?
Messages transferred will be bespoke to this application – ruling out Zigbee’s Application Layer?
Messages will be small in size, so data transfer speed is not a big concern.
I believe from what I’ve read that Thread is probably the most suitable for this use case – but wanted some other opinions to see what the best choice might be?
Seems to be a bit of a mine field to fully understand the ins and outs of all of these mesh protocols!
I believe Thread/OpenThread addresses all of the use case items you listed above.
We are planning to use Ethernet bus topology (wiki). The reason using this very old topology is hardware limitations and software requirements. Collisions should be OK, as bandwitdh requirement is very low.
My problem is, how can we test this topology with modern Ethernet controllers and software like Ubuntu etc. I could not find a good implementation example.
I have tried connecting three Intel Ethernet controllers (with Static IPs) together and only two of them had link at a time (they worked in point-to-point connection as usual)
"Modern" hardware is rather limited when trying to build a bus topology - it's much easier to build a more usual star/tree network. However, with the right key components you can even connect both topologies.
From the software point of view, the network just "works", i.e. as long as the network is configured correctly the software applications can (and should) be oblivious to the network layout.
With an assumed Ethernet network, the logical structure of each segment is a bus anyway: each device can just talk to any other device, regardless of where and how they are connected.
Chromecast v2 devices announce their presence using mDNS, and they are discoverable when performing mDNS queries for _googlecast._tcp.
DNS-SD / Bonjour also support the concept of "wide-area discovery", which makes use of standard unicast DNS queries to find devices. This can be useful for more complex networking scenarios - i.e your Chromecast devices may be in one VLAN but your sender devices are in another.
However, when trawling Chromium source I found this code in mdns_api.cc which seems to indicate that the Chrome extension will only search for _googlecast._tcp.local - completely preventing wide-area DNS discovery of other Chromecast devices. Based on anecdotal testing, it seems the Chromecast iOS app and SDK also have this behaviour.
Why does the official discovery mechanism for the Chromecast Chrome extension explicitly only discover link-local Chromecast devices?
They probably didn't do "wide-area discovery" because there are a lot of gotchas in implementing it and there isn't much gain to be had.
Let's suppose that they did implement it (from looking at the spec, it doesn't seem to be technically difficult; seems like it is mostly an edge-case problem).
You'd need:
A domain under your control. Could be a local-only domain.
Not many people do this.
Multiple VLANs that you want to use.
Most homes only have a single VLAN.
A DNS-SD server that supports Wide-Area Discovery.
This is probably the easiest thing to have. Even then, most people wouldn't do it.
A UX flow to input the various WAD servers that you want to ping for devices.
This is the hard part for Google since it needs to be consistent across all SDKs and using a WAD-discovered Chromecast would cause all local-media-server Apps to not work (e.g. Plex).
(1) - (3) are why Google wouldn't make this a priority. Chromecast is, after all, a consumer device and consumers tend to have simple networking situations. (4) is why it isn't low-hanging fruit.
You'd also need to solve a few problems:
What happens when you are connected to a Chromecast on a separate VLAN and then remove it's WAD server?
What if the WAD server goes offline?
What happens when you have multiple Chromecasts with the same name?
What if they also have the same IP address (possible since VLANs can have overlapping IP spaces)?
What happens when a Chromecast is discoverable using WAD but not reachable?
Should they attempt a connection to every single Chromecast you discover to test that it is reachable?
How would you scale this out to work with 100s of Chromecasts in VLANs that could be "far" away?
It is these problems that I think would prevent Google from implementing WAD even if they wanted to.
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "