A quick blog post today about a super useful feature that must have been in the Linux ‘tail’ command for ages of which I only recently became aware: The upper case -F option.
For many years now I’m operating a Prosody XMPP server at home for private messaging between family members and friends. Together with Conversations on Android devices and the Dino App for Linux it’s the perfect solution. There is one client device, however, to which messages sometimes take a couple of minutes to be delivered. Also I noticed that it frequently reconnects to the XMPP server. That client device is usually connected to a French mobile network so I assumed that they probably have a very short NAT timeout on their gateway that kills the TCP session to the server before either the client or the server sends some sort of keep-alive message. Not a big deal so far but since Conversations has been extended with voice and video calls, call establishment fails to the device every now and then. Time for having a closer look.
Sometimes when I get visitors I am politely asked for the Wi-Fi password of my network. No problem with that but as my password even for the guest Wi-Fi is a bit complicated it’s a pain to type it in. A nice solution: My Wi-Fi router can display a 2D bar code in the Web-UI which most mobile devices can read today either in the camera app or with a separate bar code app and detect that it contains Wi-Fi configuration information.
While this works very nicely with my router at home, I do have some Wi-Fi access points that don’t have this function, so I was wondering how I could generate such a bar code myself.
Recently, I had a look at a number of frameworks to push notification messages to my mobile device based on trigger events of my cloud at home. Think of getting a notification when a service starts misbehaving or crashing, disk drives about to become full, backups finished, etc. So far I’ve used emails and XMPP messages for the purpose. While that works great it doesn’t really fit the purpose. So I was looking for something else and discovered Gotify, ‘a simple server for sending and receiving messages’.
Installation is super easy and I was up and running in just a few minutes. Also, pushing messages from the shell or in programs written in Python and other languages just requires a single line of code. On the wire, HTTP push and Websockets are used and TLS encryption with Letsencrypt certificates are thrown in for good measure. Nice! When I had a look at the traffic to and from my mobile device to the Gotify app, however, I was a bit surprised, to say the least.
For today, I have a screenshot of two bandwidth graphs of a recent working day at home which shows the different applications I use Internet connectivity for. As in the previous blog entries on the topic both graphs show the same timeframe. While the bottom graph shows the complete downlink channel bandwidth of 100 Mbit/s in the downlink direction and 36 Mbit/s in the uplink direction, the upper graph is capped at 10 Mbit/s to show things in more detail.
Like so many other events recently, the Vintage Computing Festival Berlin (VCFB) will hold its annual event in the virtual domain this year. Other retro computing events have already taken place online in 2020 and I very much enjoyed to join events I could not have gone in person. However, all of them have focused on talks while the exhibition of retro computing equipment was unfortunately ditched. At the online VCFB this year, we attempt to do things a bit differently.
After the introduction of my network statistics data collection system in the previous post I can now analyze my line usage over time in detail. Here’s a screenshot that shows a number of overlapping data flows.
One thing I wanted to have for a long time was a better visibility of how my DSL line at home is utilized over time. My Fritzbox router has some basic functions for this such as showing the uplink and downlink utilization of the past few minutes and a daily, weekly and monthly traffic counter. That’s a start but the amount of information is limited and so are the conclusions that can be drawn from it.
Beyond these features, however, the Fritzbox has a number of counters that are updated every few seconds which can be queried over the network. Sounds promising! Together with the Grafana visualization suite that I also wanted to have a closer look at for quite some time now, it made for an interesting project. So I started searching a bit and found out that a number of other people have been at this point before as well and have put together a complete data collection and visualization front-end for the information provided by the Fritzbox. Perfect, exactly what I was looking for!
Not meeting in person but in online meetings these days has the advantage, or disadvantage, you decide for yourself, that you can also participate while on the road. While I try to avoid this as much as possible as I prefer a bigger screen and a quiet environment for meetings, the only alternative sometimes is not to participate at all. Surprisingly I found that conference calls while on the road work better than I anticipated at first.