LoRaWAN stands for Long Range Wide Area Network. It’s a standard for wireless communication that allows IoT devices to communicate over large distance with minimal battery usage. At the time of writing this article I found that information about LoRa was rather sparse or overly complicated. Since it took me some time to really figure out what LoRa is and how it works, I decided to create this post and try to explain LoRaWAN in a technical but simply understandable way.
When testing or experimenting with LoRa, a test device that can send/receive LoRa packets on demand is a real value It allows you to test the network functionality and coverage. The Adeunis RF LoRaWAN Demonstrator is such test device. It can send and receive LoRa packets, has a built-in accelerometer and GPS and rechargeable battery. THis post explains how to configure the LoRaWAN demonstrator and add it to a network server.
The Microchip RN2483 is a LoRa class A module widely available. In a normal, end-user scenario, LoRa endpoints (or devices/sensors) come with preconfigured parameters but before the module can be used, it needs to be configured with those parameters to use it in the LoRa network. What parameters to configure depends on the type of activation. For this post, I’ve been using the RN2483 based PICtail test-board.
After passing the first exam required to get a CCNA DC certification: DCICN (640-911), obviously, I was also studying for the second exam: DCICT (640-916). As this exam brought less surprise to me in terms of exam content, it was still a lot of information to process and study. Especially since I got a lot of info from different sources and to help me with studying, I decided to do the same thing as with the first exam. You can find the information which I gathered to pass the exam in this post. Hope it helps.
The Cisco Data Center certification track is quite new and I read that a lot of people fail on their first attempt(s). To get the CCNA-level of Data Center, you need to pass two exams: 640-911 DCICN and 640-916 DCICT. After giving a first look at the objectives for DCICN, it looked to me like CCNA Routing & Switching but on the Nexus platform. Well, after my first attempt to pass the exam, I realized that it requires a lot more studying and that the official books do not completely cover the exam objectives. In this post, I’ll try to explain what I studied to pass the exam.
Recently, I was asked to find a solution or workaround for people using Gmail and are visiting countries where there’s limited or no access to Gmail. I’m not talking about bad internet connection quality but about an explicit (government) block on Gmail or related websites. An example is the block on Gmail by the Chinese Great Firewall. While there is a possibility to avoid the limitation by using a normal proxy or VPN connection, those methods are also actively blocked and monitored. A workaround is to setup your own webmail, as a proxy for Gmail.
When regularly installing Linux hosts or VM’s, it easily becomes annoying to constantly burn CD’s/DVD’s or mount ISO’s for all the Linux distributions that you want to deploy. Especially if you want to keep them current or customize them you’ll end up with a whole lot of discs. Booting your installations from the network, using a PXE boot server, makes life a lot easier and isn’t very hard to setup. In this post I’ll explain how to setup such a PXE boot server that is able to provide multiple Linux distribution installations for deployment over the network.
When configuring a Linux host running either Red Hat Linux 6, Red Hat Linux 7, CentOS 6 or CentOS7 with two network interface cards (NIC) that each have an IP address in a different network or subnet, you could end up in a situation where one of the IP addresses isn’t reachable outside it’s own network. Both IP’s will be responding to a ping from another host in the same network as those IP addresses but only one is responding to ping from another network. On most other distributions, like Debian, this issue, which is caused by asymmetric routing, doesn’t seem to exist.
When configuring a cluster, you want tot keep managing the server as simple as possible. Theoretically, the results given by any node in the cluster should be equal as you want the cluster to be transparent to the end-user. Part of doing this, is having the same data available on every node of the cluster when it’s active. One way to do this, is using a central file-share, for example over NFS but this also has disadvantages. Another way is to have a distributed file system that stays on the nodes itself. DRBD is one of them. This post explains how to integrate DRBD in a cluster with Corosync and Pacemaker.
Besides using NAT for accessing the internet with multiple machines using a single IP address, there are many other uses of NAT. One of them is to forward all traffic that is sent to a certain TCP port to another host. In practice, this technique can be used to test a service on a new host without adjusting anything on the client. The users or the clients do not need to be pointed to a new machine in order to test it. When the test would be unsuccessful, removing the NAT-rule is all it takes to switch back.