crush depth

JDK Support Range Change

I'm considering changing the range of JDKs I support.

Right now, I specify JDK 11 as the target bytecode level. That is, you require at least JDK 11 to run any code I write. I specify the range of allowed compiler versions as [11, 14]. That is, you can build the code on any JDK newer than 11 but older than 15.

I'd like to adjust this a bit to reduce the range of JDKs upon which I test code. Specifically, these would be the new rules:

  1. The target bytecode level is CurrentLTS. That is, you require at least JDK CurrentLTS to run any code I write.

  2. The set of allowed compiler versions is [CurrentLTS, CurrentLTS + 1), [Current, Current + 1).

At the time of writing, CurrentLTS = 11 (the next value of CurrentLTS will be 17), and Current = 14.

So under the new rules, at the time of writing, you could run the code on JDK 11, 12, 13, and 14. You could build the code on JDK 11, and any JDK greater than or equal to 14 but less than 15. This slightly odd-looking range is necessary because JDK compiler versions contain minor and patch levels such as 14.0.2. The explicit support statement would be that only JDK versions upon which the code is regularly built and the test suite executed would be supported. You could run the code on JDK 12 and 13, but you'd be on your own there as the code is only built and tested on 11 and 14.

This would reduce the number of CI builds I need to execute on each commit from at most six (11, 12, 13, 14, 15, 16) to exactly two (11, 14). With project counts in three figures, the build counts quickly add up!

MAC Address Conflicts Hurt

I've been running a server on my LAN here for a couple of years. This week, I built a new machine and am in the process of trying to migrate to the new hardware.

However, something odd happened... With an SSH connection open to the old server (cranberry), I booted the new server (vanilla). The open SSH connection began to sporadically and repeatedly hang and then come back to life. Shutting down vanilla caused the problem to go away. Some investigation with Wireshark showed odd TCP Retransmission events occurring, which I don't think I've ever seen before and certainly shouldn't be happening on a LAN.

Sometimes, SSH connections to vanilla would work fine, and the connections to cranberry would hang/resume instead. I couldn't determine any reason for this to be happening; all my hardware is in good shape.

Then, I tried to nmap vanilla and cranberry from my workstation...

$ nmap -vvv cranberry
...
MAC Address: 58:9C:FC:10:93:1F (FreeBSD Foundation)

$ nmap -vvv vanilla
...
MAC Address: 58:9C:FC:10:93:1F (FreeBSD Foundation)

I was firstly surprised at seeing a MAC address conflict, and then doubly surprised at seeing the string "FreeBSD Foundation" in what should be a hardware identifier.

Looking at ifconfig on cranberry and vanilla, I see:

$ ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 58:9c:fc:10:93:1f

$ ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	ether 58:9c:fc:10:93:1f

I'd created bridge devices on both machines to which to attach TAP devices for bhyve virtual machines. Evidently the generated MAC address on both was the same, and this MAC address leaked out onto the LAN. Packets would essentially arbitrarily go to either machine if both happened to be switched on at the same time.

The manual page says:

  The if_bridge interface randomly chooses a link (MAC) address in
  the range reserved for locally administered addresses when it is
  created. This address is guaranteed to be unique only across all
  if_bridge interfaces on the local machine.  Thus you can
  theoretically have two bridges on the different machines with the
  same link addresses.  The address can be changed by assigning the
  desired link address using ifconfig(8).

Moral of the story: Assign your own MAC addresses to virtual devices. Pick an unused area in the MAC registry and go wild.

The Vanishing Path 1

The Vanishing Path 1

Source

New PGP Keys

It's that time of year again.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Fingerprint                                       | Comment
- -------------------------------------------------------------------------
E369 81ED 130D B4F6 8D42 0248 BBFF DB75 5BAE D95D | 2020 personal
406D 6CE4 6463 FA78 8ABB 63A3 6AF3 0ECF 4211 F11C | 2020 maven-rsa-key (RSA key to sign Maven Central releases)

-----BEGIN PGP SIGNATURE-----

iIQEARYKACwWIQTjaYHtEw209o1CAki7/9t1W67ZXQUCXgyzMw4cbWFya0Bpbzdt
LmNvbQAKCRC7/9t1W67ZXfhhAP4oSb5KTnJ84ZSKkArxSU6tRFhYdnVK7tRK2SWx
P1fKlwD/XdIb2ZsJ2U7UerpfPQ2e+MEhg0J+h6wHak+lOow96ww=
=kZge
-----END PGP SIGNATURE-----

Keys are published to the keyservers as usual.

Dimenec

Dimenec