In my time at Utrecht University computer science I wrote a script to search Cisco switches for a given ethernet address and respond with the port. This could be used to trace things on the network, which helped on incidents in progress.

This script was based on the typical things Cisco switches do with vlan CAM table lookups and the best implementation. CAM stands for Content Addressable Memory: memory optimized for doing lookups by certain content. In the case of a network switch a 6-byte MAC address plus 2-byte vlan id will be used to do a lookup of the 2-byte interface number where it was last seen, and this lookup is done in hardware.

This CAM table is accessible via SNMP, and the funny part is the MAC address for the lookup is also encoded as SNMP identifier. I could get the whole CAM table via snmpwalk but as I only want to lookup 1 MAC address it is way faster to go directly from MAC address to interface number. After that the interface number is translated to an interface name and that name is usually something recognizable to a network engineer.

When I started using managed switches at home from Netgear I adapted the script at home and enhanced it for Netgear switches.

I recently added a third netgear switch when upgrading the fiber to the shed and I updated the script to learn about the new switch.

I noticed the interface names are quite different over the generations of netgear switches.

The oldest switch is a Netgear GSM7224. The interface name from a query is "Unit: 1 Slot: 0 Port: 15 Gigabit - Level".

The second switch is a Netgear GS716Tv2. The interface name from a query is "Slot: 0 Port: 11 Gigabit - Level".

The newest switch is a Netgear GS310TP. The interface name from a query is "GigabitEthernet9".

The Unit: 1 in the GSM7224 suggests some option for stacking multiple switches, but I can't find any mention of that option in the on-line documentation.

The other fun part I notice is interface names never showing the fact that they are actually an SFP interface with an SFP in them. The port status for a port with an SFP is not different from the status for a copper cable at gigabit.

Na het aanpassen van het netwerk naar de schuur naar gigabit was ik natuurlijk ook de monitoring van de SolarEdge inverter met modbus/tcp aan het testen. En toen viel me even iets op, de inverter stond in mode THROTTLING en dat was me nog niet eerder opgevallen.

De uitvoer is dan

$ ./sunspec-status -v se-schuur -m 0
INVERTER:
             Model: SolarEdge  SE2200
  Firmware version: 3.2537
     Serial Number: xxxxxxxx

            Status: THROTTLING

 Power Output (AC):          342 W
  Power Input (DC):          348 W
        Efficiency:        98.50 %
  Total Production:     3964.313 kWh
      Voltage (AC):       237.40 V (49.94 Hz)
      Current (AC):         1.53 A
      Voltage (DC):       378.80 V
      Current (DC):         0.92 A
       Temperature:        42.75 C (heatsink)

Ik kon niet vinden wat de reden was van het terugregelen van het uitgangsvermogen. Ik log nu wel de statuswaarde van de inverters om te zien of dit vaker voorkomt.

Update: Achteraf denk ik dat dit gekomen is omdat ik de omvormer in de schuur gereboot had om het juiste IPv4 adres te krijgen voor monitoring. Dit was op een best wel zonnig moment. Na de reboot was ik snel aan het testen of de modbus/tcp monitoring het deed naar het nieuwe adres, en de omvormer gaat niet in een klap voluit electriciteit leveren maar brengt dat langzaam op gang.

I got around to doing the upgrade of the fiber to the shed network I had on my mind today.

A friendly network layer 1 engineer had some leftover Cisco SFP modules and the netgear GS310TP and netgear GS716Tv2 switches accepted these without any issue. So the layer 1 network link came up fine.

The layer 2 link with vlan support took me a few hours, somehow I managed to get confused with vlan tagging, vlan tagged only frames and the primary vlan id. I haven't done this in a while and I sort of copied the configuration from another port which may be less than optimal too. I had to run through the house a number of times to get the configuration right, wireless devices can't access the managed switches. At least I got the whole configuration working in the end. I think I can add other vlans to the link too (I want the option of a wireless access-point in the shed).

Putting the switch, the power supply for the switch, the raspberry Pi, the power injector for the 1-wire measurement network and all network cables and fiber in the plastic box I bought for this work was a bit of work, it just fits (so a wireless access point will have to live outside that box..). But it's all in there and the box is closed again. It's just not airtight anymore with the new holes for power, fiber, network cable, gps antenna cable and 1-wire network. I may need to stuff the holes with foam or something similar to keep insects from crawling into the box.

Everything works now and the measurements from the solar inverter are coming in!

After reverting to Grafana 8.4.7 for a while because alerts were failing in Grafana 8.5.0 I had a look at the available version today and saw version 8.5.2. I assumed the problem with DataSourceNoData errors was fixed by now and did the upgrade.

Indeed the alerts are seeing data fine now and I trust they will work when needed.

A notable and rare country in the log today: Iran. I've seen Iranian calls on the air a few times but it is rare. Today I saw EP2C on the air in FT8 in the 17 meter band and got the contact.

Confirming it is the next step: they have a QSL manager so I'll have to pay a few euros to get a paper card. Although the call seems active on Logbook of The World.

I installed Grafana from their debian repository, so I get updates via the normal apt update / apt dist-upgrade process. Since upgrading to version 8.5.0 the alerts were all firing because of 'DatasourceNoData' errors. According to Alert Rule returned no data (after upgrade to 8.5.0) #48128 other people are seeing this too.

For now I downgraded to version 8.4.7 where things work fine and I'll see if a newer version shows up.

In October 2018 a morse course started at my local radio club under the leadership of Ab PA5ABW. Around March 2020 the people still going strong practising morse thought they had a chance of passing the morse exam in Belgium. But that pandemic happened, borders closed and gatherings of radio amateurs were impossible.

Why go to Belgium? The Dutch telecommunications authority does note whether you have 'CW included' or 'CW not included' but there is no exam possibility in the Netherlands. So in the past doing the exam in Belgium, presenting the certificate to the Belgian telecommunications authorities to get it converted to a certificate the Dutch authoritities accepted and converting that certificate to a Dutch 'CW included' note was the way.

When there was an option of a Morse exam in April 2022 in Belgium again there was a note the Belgian telecommunications authorities were not willing to do the 'conversion' for foreign radio amateurs who weren't living in Belgium. This seemed to kill the route to get the much coveted 'CW included'. After writing an article about this a suggestion came to 'skip' the Belgian telecommunications authorities and present the Belgian certificate to the Dutch telecommunications authorities. Later there was news from the Veron amateur club: Morse examen doen in België voor een ‘CW included’ aantekening kan nog steeds with a statement from Agentschap Telecom (Dutch telecommunications authorities) stating they would accept the certificate from the UBA club in Belgium at this time.

So when that became an option we registered for the exam in Belgium and kept practising. Personally I had to change to using actual pen and paper and not a keyboard because the exam would be using paper!

Between October 2018 and April 2022 we practised for about three and a half years. That means I practised morse in one way or the other for almost every day of the week.

The three of us went to Diest last Monday and all passed the test. On Tuesday I sent scans of all the needed documents to Agentschap Telecom to get those three letters removed from the amateur radio license document, going from "CW not included" to "CW included".