Monthly Archives: December 2019

A denial-of-service attacker in my Ethernet: Philips screen 329P9H

I use a Philips P-line 329P9H screen. A strong reason for why I chose this particular model is its 1 Gbit/s Ethernet (RJ-45) port: the 329P9H has the rare property that I can attach it to my network switch with a common Ethernet cable.

When I then attach my notebook to the screen through a single USB-C cable that connection does not only transmit video data and periphery (keyboard and mouse, …) data but also Ethernet. Quite neat, right?

I thought: that way, I could easily continue enjoying the stability of a cabled Ethernet connection at my desk just like I did for most of my professional life, whereas my current notebook does not even have an RJ-45 port anymore.

I also listen to music quite a lot with my music streaming system which is connected to the Internet through the same cabled Ethernet, attached to the same Ethernet switch that my screen is attached to.

Since I have had this new screen the music stream stopped more often than before. And I couldn’t quite believe it: when the music stops and when I then unplug the screen’s Ethernet cable from the switch the music starts again, within one or two seconds.

The first time I tried this was when I ran out of options debugging the absence of Internet connectivity at my music stream device. I looked at the switch and the activity LED for the screen’s Ethernet port (on the switch) was flashing at its highest frequency. At that very moment, I did not have the notebook attached to the screen. That was fishy: where would the Ethernet activity come from if not from the (idle, sleeping) screen itself? I powered off the screen and the Ethernet (and therefore Internet) started to work again, quasi-instantaneously, for my music streaming device, and for all other devices attached to the switch.

I observed this about five times so far. It’s no coincidence, seems to be an actual fault in the screen’s Ethernet “controller”. This only seems to happen when no notebook is attached to the screen. It happens when the screen is in ‘sleep’ mode. Power-cycling the screen is sufficient to make the problem go away (until it comes back after a couple of days or weeks).

The Ethernet switch I use is consumer-grade but it is a decent 5-port 1 Gbit/s switch which has served me well over the years. Several different networking devices just worked fine with that switch. This new screen is the first device that trips up the switch.

This happened again today. I think now I leave the screen unplugged from the switch using just the wireless network from my notebook. :-(.

VS Code spell check: simplicity wins

Spell Right is a spell checker extension for VS Code. Its README is a little convoluted. Here is how to set it up on a Linux system.

Step 1: set up dictionary files:

cd $HOME/.config/Code/
mkdir Dictionaries && cd Dictionaries
git clone https://github.com/titoBouzout/Dictionaries .

Step 2: In VS Code press Ctrl+P and run

 ext install ban.spellright

Step 3: restart VS Code

Step 4: open the document to spell-check in VS Code. Then click the eye icon (similar to 👁️) in the bottom-right corner of the VS Code status bar. Select the language, press OK. The document is now being spell-checked. Screenshot:

vs code spell check with spell right

Remarks

For my use cases I prefer Spell Right over the more complex Code Spell Checker extension. Spell Right seems to be pretty similar to the simple, unobtrusive experience provided by Sublime’s built-in spell checker (which I was happy with for many years, also using the titoBouzout/Dictionaries).

Setting und using variables in a Makefile: pitfalls

A debug session. I ran into a problem in CI where accessing /var/run/docker.sock from within a container failed with a permission error. I had this specific part working before. So I did a bit of bisecting and added debug output and found the critical difference. In this case I get a permission error (EACCES):

uid=2000(buildkite-agent) gid=0(root) groups=0(root)

In this case not:

uid=2000(buildkite-agent) gid=1001 groups=1001

The difference is in the unix group membership specifics of unix user uid=2000(buildkite-agent) within the specific container. If the user is member of gid=1001 then access is allowed, if the user is member of gid=0 then access is denied.

I found that in the erroneous case I was passing this command line argument to docker run ...:

-u 2000:

Nothing after the colon. This is where the group ID (gid) belongs. docker run ... did not error out. That is no good. This input was treated the same as -u 2000 or -u 2000:0.

But why was there no gid after the colon when I have this in my Makefile?

-u $(shell id -u):${DOCKER_GID_HOST}

Because when this line was run DOCKER_GID_HOST (a Make variable, not an environment variable) was actually not set.

A shell program would catch this case (variable used, but not set) when being used with the -o nounset option, and error out. Make does not have this kind of protection. There is no general protection against using variables that are not set. As far as I know!

Okay, but why was the variable DOCKER_GID_HOST not set when I have

DOCKER_GID_HOST := $(shell getent group docker | awk -F: '{print $$3}')

right before executing docker run? Well, because this is a Makefile. Where you cannot set a variable in one line of a recipe, and use it in the next one (a pattern that we use in almost every other programming environment).

The lines of a recipe are executed in independent shells. The next line’s state is very much decoupled from the previous line’s state, that’s how Makefiles work.

This is probably the most important thing to know about Make, and one of the most common mistakes, and I certainly knew this before, and I certainly made this same mistake before. And I made it again, like probably every single time that I had to do things with Make.

Makefiles are flexible and great, and sometimes they make you waste a great deal of time compared to other development environments, man.

Stack Overflow threads on the matter, with goodies like workarounds, best practices, and generally helpful discussion: