Short story, I’m updating a Laird gateway connected to my mac book and using the Wifi connection to reach Internet. I need to get the allocated IP to access it using the web UI.
I found two ways (only one working) on Internet:
[~] ping 192.168.2.255
This way, you can get different devices responding to the ping broadcast and list the addresses. I’ve got nothing interesting but it’s good to know.
[~] arp -i bridge100 -a
? (192.168.2.5) at (incomplete) on bridge100 ifscope [bridge]
? (192.168.2.9) at xx:xx:xx:xx:44:dd on bridge100 ifscope [bridge]
? (192.168.2.99) at (incomplete) on bridge100 ifscope [bridge]
Here we have a device responding on 192.168.2.9 where the Laird is.
Helium network is a crowdsourced network using a blockchain. There are multiple transactions related to the Helium devices communication. Usually, we talk about the message transmission transaction corresponding to a flat cost of 1DC ($0,00001). That said there are some questions:
what is a message definition ?
what are the other blockchain transaction impacting the communication cost ?
In the post we are going to review the answer to these questions and I’ll propose a spreadsheet to modelize these cost with some example to see the different kind of real message cost you should take into account in your business model.
Helium is a multi network server with a decentralized packet routing system. This is really clever and allows anyone to use the public infrastructure as private LoRaWAN compatible network. That way you get benefit of a worldwide coverage and, in the same time, the ability to protect your raw data from anyone looking at them. You can also create some other public network server, as we are doing with Helium-Iot.eu
The objective of a such public service is to offer a shorter route for your European devices and as a consequence a shorter response time for downlink. It also ensure your data to stay in Europe, something important for personal data like tracking, health or for industrial applications.
For a better understanding, let’s take a look at the Helium network architecture:
Helium network architecture
Thanks to the miner components incorporated in the hotspots, the traffic from the devices is directly routed to the right network server. Each of the network servers belongs to a, operator, it can be you or me or any established telecom operator. This is basically really cool !
That’s why we have decided with the company I work for to take a look at this business and launched Helium-IoT.eu. So you can connect your devices to Helium using our console https://console.helium-iot.eu
In the next page of this post I will explain how to become your own operator for making your private network. This is a bit complex operations, so if you want your own network server, as part of our services we are proposing to make it for you and host it. We also have solutions to migrate existing LoRaWan networks to Helium. Just let us know by contacting me with the contact link.
So, let’s be more technical to understand all of this.
The BalenaFin board, made by balena.io is a compact Raspberry Pi compute module 3 mother board.
This kind of setup is really useful when making industrial embedded systems in small to average volume like I did and described in a previous post presenting my solution on waveshare system.
I thank you Balena.io, especially Marc, for giving me the opportunity to test this product. So you understand I did not payed to get that one, but as usual, I’m totally free about what I’m writing about it.
The BalenaFin costs $129 w/o taxes and can be ordered on the balena shop. So, let’s how to use it and get benefit of the balena.io platform.
I’m teaching processor architecture since about 20 years from now using Arduino (more recently) as a platform for practicing some low level development to understand the architectural principles. This year with Covid-19 I had to give it online and it has been the opportunity to release a new version of the support and recording it.
If you understand French, you can follow this courses online on my Youtube channel
You can also get the slides with the following document:
Announced during TheThingsConference 2021 this January, TheThingsNetwork console is upgrading to v3. In fact it is really more than a simple update because this consist in merging TheThingsNetwork and TheThingsIndustrie in a common environment. This upgrade is really different than a traditional upgrade because it has an impact on any gateways and any devices ; a big impact anyone needs to manage. Here are some of the currently known impacts on the networks and the different components:
Traffic from v2 is routed to v3 but v3 is not routed to v2
Gateway are not migrated automatically
LoRa Application/Integration needs to be re-created in v3 to communicate over v3
Device LoRaWan session needs to be refreshed
Coverage map are lost
Gateways using gRPC protocol (TTN Packet forwarder won’t relay V3 traffic over V2)
… some more to be discovered
As the Network is managed by many different people, and not really planned and organized by TheThingsIndustry, we are going to have disconnections and fields operations to make all of this back to life.
It concerns the TTN Initiators (people deploying the network) but also the TTN users because they need to update Applications and restart/rejoin devices once the V2 has disappeared.
The currently know planning for Europe is (Other countries not yet planned)
April 2021 – v2 console will be read-only (you won’t be able to add devices / gateways)
September 2021 – v2 infrastructure will be switched off, no more communication on it
This blog post details my advises and experience of the migration. As I’ll do it in different waves for practical reason, this post will be updated. So please come back and refresh all along the months of February-March 2021 to get the updates, content and advice will be updated according to my progress.
Personal current advice about migration: START INVESTIGATING SINGLE DEVICE MIGRATION
I had some difficulties to migrate my first device and this has been solved by upgrading the gateway and redefining it in the TTNv2 backend. Discovering such situation earlier is important to get on time for upgrading. I recommend to start migrating 1 device to identify such situation. Migrating more than a device could still means impossible ways for some of your devices to communicate through v2 infrastructure. But it will help to prepare your infrastructure for migration.
A recent publication analyzed the Sigfox protocol security, This is the most advanced work I’ve seen on this so it is interesting to go to some details about it. The author is Loïc Ferreira working for Orange Labs, Applied Cryptography Group at Caen,France. This report has been shared with Sigfox by the Author on August 2020.
In this post, I’ll not challenge any of the outcomes from Loïc as it is a serious researcher. What I want to do is to highlight this with the ability for someone to use this to make a successful attack against a device and in what conditions.
I love to say, in the security domain, that sometime, IoT attacks are like explaining how to destroy earth and humanity by changing the course of the moon to make that one crashing on its target: Theoretically it is possible, technically we could find ways to make is possible for an extraordinary cost. Practically speaking, the one doing it will also kills itself, so there is no big gain to expect.
So, let’s take a look to the different breaches reported on the publication…
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptReject
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
