Gave a presentation at the Sonatype User
Conference
back on 2020-08-12 on how the Library
Simplified project uses
Maven Central and the principles of
modularity to develop
and deliver Android components.
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:
-
The target bytecode level is
CurrentLTS. That is, you require at least JDKCurrentLTSto run any code I write. -
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!
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.