News items for tag english - Koos van den Hout

2021-07-29 Zigbee - zigbee2mqtt - mqtt-to-influxdb-forwarder - influxdb - grafana working 1 month ago
It may seem like a complicated stack compared to monitoring with rrdtool, but the wireless environmental monitoring with zigbee plans are starting to work. The zigbee stick arrived, I found out I needed to upgrade the Raspberry Pi in the utility closet to be able to run zigbee2mqtt so I did that: Raspberry pi monitoring the smart meter is now installed and the zigbee environment sensors arrived and the first one joined the network. After some changes to mqtt-to-influxdb-forwarder I was able to get the data into influxdb.

The final step was to tell grafana where to find the data and create a dashboard visualizing the results, see the screenshot.

I'm also improving small things in using zigbee sensors and improving data collection. After learning about not leaving the network running with permit_join true I had a look at the configuration messages I can send to zigbee2mqtt. It is clear zigbee2mqtt is not just from zigbee sensors to mqtt messages but also the other way around, both to adjust settings in zigbee2mqtt itself and to send commands to zigbee devices.

I did change the friendly_name of the first sensor to the name of the room it is in, and it's now showing up in the statistics under that name. This does break the history, so I should change the name as soon as I add a sensor to the zigbee network.

Tags: , , ,
2021-07-27 Less logging in zigbee2mqtt to save the MicroSD in the Raspberry Pi 1 month ago
The recent MicroSD failure in the Raspberry Pi made me look at the logging in zigbee2mqtt as it is running for a long time and default logging includes every received message which would give a lot of wear on the MicroSD in the Raspberry Pi. So I changed the configuration to only log to console.

This is something that can't be changed via an mqtt message, which is logical (otherwise it would have security implications).

I may also look at less system logging to the MicroSD. Someone suggested to have a look at log2ram for this. This creates a ramdisk for logging which is synchronized to persistent storage every day or on shutdown.

Tags: , ,
2021-07-26 MicroSD failure in a Raspberry Pi 1 month ago
The Raspberry Pi in the attic running mainly dump1090 and some other software wasn't showing up in the system monitoring. On checking it turned out the MicroSD card was failing. This is a known issue in the Raspberry Pi which uses MicroSD as root filesystem. For as far as I can tell this card has been running continuously since February 2016, so over five years.

I do have a different MicroSD card which is the old card from the Raspberry Pi in the utility closet which became available after I used a different card to reinstall the Raspberry Pi for smart meter monitoring. But that card has seen some wear since it has been running since installing the smart meter and starting energy monitoring on it in August 2016 so maybe it's not a good idea to rescue a system with it, it's also five years old.

Time to order some new MicroSD cards! In the mean time I noticed I could get a bit of access to the broken card, but things stopped on mounting the linux root filesystem. It turned out that mount tries to write to the card to update the ext4 journal and the card stops completely on a write. When I mount it really readonly with
# mount -o ro,noload /dev/sdb2 /mnt/scratch/
almost all files are readable, so I recovered the dump1090 software and other configuration items. Yes, I need to add the Raspberry Pi systems to the backups.

It would be really nice if I could monitor the health of the MicroSD card like I monitor other disks (including SSD) with smartmontools.

Update: Three MicroSD cards ordered so I can replace this one and have a few spares ready. The size of those cards does mean I now have to make small bags labeled 'spare' or 'old card from system X' so I can see what they are without trying to mount them.

Tags: ,
2021-07-24 I participated in the King of Spain SSB contest 1 month ago
At the end of June was the King of Spain SSB contest and I participated for a while. I just never wrote about it, but this week the log check report came in. With... 0 errors!

In total I made 34 contacts, 2 on the 15 meter band and 32 on the 20 meter band. So I entered as all-band station and I won't be ranked very high. I used the remote radio to get good reception on HF and have access to the 15 meter band.

Tags: , ,
2021-07-12 I participated in the IARU HF World Championship 2021 2 months ago
This weekend was the IARU HF World Championship contest and I participated after fully planning this in advance. I made sure my contest logger was set up and communicating with the radio and the morse keyer in advance.

I participated on the 10, 15, 20 and 40 meter bands. In total 125 contacts. 70 in SSB (speech) and 55 in CW (morse).
Band   160   80   40   20   15   10
QSO's    0    0   32   53   32    8
Mult     0    0   22   24   13    8

Pts: 381  Mul: 67 Score: 25527
I had more trouble decoding morse than I hoped for and conditions weren't ideal. Not a lot of stations outside Europe, a few Asian ones and one US station in morse.

First conformations showing up on Logbook of The World, which gives me Bosnia-Herzegovina on 15 meters confirmed and Bosnia-Herzegovina and Switzerland confirmed in CW. Always nice to get some new things in the log but I usually only see that after the contest.

Raw score calculation when I submitted the log:
261 Qpts x 65 Mults = 16,965 (one or more Zones/HQs in the copied exchange not recognized).
I guess the problem with the exchange is with EO0HQ in Austria giving OV and not OVSV as expected but I am 100% sure I copied that correctly.

Tags: , ,
2021-07-12 Checking the rcu_sched messages finds repeated mention of cdrom scans 2 months ago
I was going through some rcu_sched messages and noticed kernel routines related to the cdrom drive showed up a few times in the tasks that were 'behind'.
[335894.319961]  [<ffffffffc03d864a>] ? scsi_execute+0x12a/0x1d0 [scsi_mod]
[335894.320702]  [<ffffffffc03da586>] ? scsi_execute_req_flags+0x96/0x100 [scsi_mod]
[335894.321820]  [<ffffffffc04a7703>] ? sr_check_events+0xc3/0x2c0 [sr_mod]
[335894.322551]  [<ffffffffb58224a5>] ? __switch_to_asm+0x35/0x70
[335894.323256]  [<ffffffffb58224b1>] ? __switch_to_asm+0x41/0x70
[335894.323906]  [<ffffffffc047d05a>] ? cdrom_check_events+0x1a/0x30 [cdrom]
[335894.324545]  [<ffffffffc04a8289>] ? sr_block_check_events+0x89/0xe0 [sr_mod]
[335894.325186]  [<ffffffffb551a9a9>] ? disk_check_events+0x69/0x150
Because the virtual machines don't do anything with the virtual cdrom after the first installation I'm removing them from all virtual machines and see what that does for these messages.

Tags: , ,
2021-07-08 Another panic in a virtual machine 2 months ago
At the end of this morning I noticed the root filesystem of the shell server on the homeserver had turned itself read-only. Another DRIVER_TIMEOUT error in the kernel messages. And I didn't want to get to a situation with half of the filesystem in lost+found like the previous time.

This time I decided to use a different approach in the hopes of getting back to a working system faster. And they worked this time.
  1. echo s > /proc/sysrq-trigger to force a sync
  2. echo u > /proc/sysrq-trigger to force an unmount of all filesystems
  3. I killed the virtual machine with virsh destroy (the virtualization equivalent of pulling the plug)
  4. I created a snapshot of the virtual machine disk to make have a state of file system to return to in case of problems in the next steps
  5. I booted the virtual machine and it had indeed filesystem issues
  6. So reboot in maintainance mode and did a filesystem check
  7. After that it booted fine and the filesystem was fine, nothing in lost+found
After things ran ok for a while I removed the snapshot. I also changed the configuration to use virtio disks and not ide emulation. Ide emulation disks have a timeout (DRIVER_TIMEOUT) after which things are given up. The fact that (emulated) I/O hangs for 30 seconds is bad, but maybe related to the rcu_sched messages. Maybe time for some more updates.

Tags: , ,
2021-07-06 Bitcoin extortion spam showing up on different e-mail addresses 2 months ago
I was digging for leaked addresses in my spambox and found a fast way to find a lot of them: by searching for bitcoin extortion spam. A pattern emerges:
Obviously, I have easily managed to log in to your email account (ambe.at. domain).
Obviously, I have easily managed to log in to your email account (chellinger.org.at. domain).
Obviously, I have easily managed to log in to your email account (eenheld.at. domain).
Obviously, I have easily managed to log in to your email account (owelladjecroecvn.at. domain).
Obviously, I have easily managed to log in to your email account (ubmitwolfn.at. domain).
Obviously, I have easily managed to log in to your email account (ubmitwolf.at. domain).
Obviously, I have easily managed to log in to your email account (ambecomment.at. domain).
Obviously, I have easily managed to log in to your email account (ziggo.nl.at. domain).
Obviously, I have easily managed to log in to your email account (wisecommunications.at. domain).
There is very little spread in buttcoin wallets:
$ grep -h 'bitcoin wallet' * | sort | uniq -c
      2 Here is my bitcoin wallet: 12kieSEdCV4ikxdXXXC23ZsDcNmmKrRmwA (over 16600 dollar received)
     19 Here is my bitcoin wallet: 1665CsfFELrfiiubFZtLsGHGuqbUz1wXcz (over 14300 dollar received)
      1 Here is my bitcoin wallet: 1CYBbByg3eXE9LRUwh6j7ZMtFrJJyFcAcP (over 2400 dollar received)
      3 Here is my bitcoin wallet: 1LjGz2WcECaNpK1ajWcpsPEQFSxrw5DxMM (over 14400 dollar received)
Who says crime doesn't pay? Again, the author has no idea who pays, but likes a filled bitcoin wallet.

This also shows that spammers maintain really old address lists and don't mind adding more addresses by using databreaches or adding or removing letters from e-mail addresses.

Tags: , ,
2021-07-03 Trying a DNSSEC zone signing key (ZSK) rollover 2 months ago
Time to do a zone signing key (ZSK) rollover. That rollover is relatively easy because I don't need to synchronize it with the DS key in the parent zone.

I generated a 'successor' key for camp-wireless.com and set a short-notice publication date. The old ZSK has keytag 02908 and the new one has keytag 25619. There is an overlap of a month in which both keys are seen as valid because caching of DNS answers mean there can be signatures created with the old ZSK in caches.

Generating a signed zone after the validity of the new ZSK has started shows both ZSKs signed as valid. Old and new zone signing key:
; This is a zone-signing key, keyid 2908, for camp-wireless.com.
; Created: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Publish: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Activate: 20190704113915 (Thu Jul  4 13:39:15 2019)
; Inactive: 20210705000000 (Mon Jul  5 02:00:00 2021)
; Delete: 20210805000000 (Thu Aug  5 02:00:00 2021)
camp-wireless.com. IN DNSKEY 256 3 13 lXntnbvQqHy+OSG/2RpHEbcYzeUAB2tFE+d5Us9M07Ndw7TI2DF2TIDx vC3bPomCE2102FJSr8/DnzoRiMHreg==
; This is a zone-signing key, keyid 25619, for camp-wireless.com.
; Created: 20210702115321 (Fri Jul  2 13:53:21 2021)
; Publish: 20210703000000 (Sat Jul  3 02:00:00 2021)
; Activate: 20210705000000 (Mon Jul  5 02:00:00 2021)
camp-wireless.com. IN DNSKEY 256 3 13 kJpmrljuP7PncZij7G1Yn9xngKe1xUpuONG2XAx8AYXu//qXClAbgg3B bmzyeDpFAw2gDRhjQ7f5o20c1QK9OA==
So I generated the key on 2 July 2021, with a set publication date of 3 July 2021. I shortened the prepublication period to avoid problems with other things happening in the near future and today it changed to published. If I generate new signatures again on 5 July 2021 those will use the new key.

DNSSEC is a process with lots of things to get your brains around, and a key rollover is one of those things. A key signing key rollover is even harder because uploading of the public key to the registrar has to be kept synchronized with the published information. That is why I am testing all this on camp-wireless.com where it is not a major problem if something fails.
Read the rest of Trying a DNSSEC zone signing key (ZSK) rollover

Tags: , ,
2021-07-03 Forgot about zigbee2mqtt running with permit_join true and 2 devices joined my zigbee network 2 months ago
I sort of forgot I had zigbee2mqtt running since 18 June and the network enhanced itself with two devices: a 'lidl smart plug' and a 'power supply/relay/dimmer'. The Lidl Silvercrest smart plug (EU, CH, FR, BS, DK) (HG06337) left the network by itself but the Busch-Jaeger Zigbee Light Link power supply/relay/dimmer (6735/6736/6737) was actively reporting and I was able to switch the light on and off.

After resetting it to the state I found it in I tried to remove it from the network (by sending a 'remove' message to zigbee2mqtt) but it came back right away. So I stopped zigbee2mqtt, set permit_join to false and restarted it. After that I gave the 'remove' command again and that worked and it hasn't come back.

Log from zigbee2mqtt with the device id removed:
Zigbee2MQTT:info  2021-07-03 15:59:04: MQTT publish: topic 'zigbee2mqtt/0xd85def11a1004f69', payload '{"brightness_relay":254,"linkquality":33,"state_relay":"OFF"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: Removing '0x****************'
Zigbee2MQTT:info  2021-07-03 15:59:08: Successfully removed 0x****************
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"0x****************","type":"device_removed"}'
Zigbee2MQTT:warn  2021-07-03 15:59:08: Device '0x****************' left the network
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"ieee_address":"0x****************"},"type":"device_leave"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x****************"},"type":"device_removed"}'
Zigbee2MQTT:warn  2021-07-03 15:59:08: Device '0x****************' left the network
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"ieee_address":"0x****************"},"type":"device_leave"}'
Zigbee2MQTT:info  2021-07-03 15:59:08: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"left_network","meta":{"friendly_name":"0x****************"},"type":"device_removed"}'

Sorry to whoever in the neighbourhood wasn't able to get their new lightswitch/dimmer working with their own hub. It should work now.

I checked the documentation and it's perfectly possible to tell zigbee2mqtt to allow/deny joins (even for a set time) via a message delivered via mqtt: MQTT topics and message structure: zigbee2mqtt/bridge/request/permit_join. I will leave the fixed configuration to joins disabled and will allow a join by hand when there is an actual device to join.

Tags: , ,

IPv6 check

Running test...
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred. PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers

RSS
Meningen zijn die van mezelf, wat ik schrijf is beschermd door auteursrecht. Sommige publicaties bevatten een expliciete vermelding dat ze ongevraagd gedeeld mogen worden.
My opinions are my own, what I write is protected by copyrights. Some publications contain an explicit license statement which allows sharing without asking permission.
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews
This page generated by $Id: newstag.cgi,v 1.34 2020/12/31 15:36:31 koos Exp $ in 0.017981 seconds.