The Wingnut Diaries

"Wissen macht traurig"

Feb 2

Nest Protect announces strange IPv6 routes (and messes up my home network)

Since a few weeks, strange things started to happen in my home network.

After a while, but pretty reliably within a day or so, my hosts sprouted a new IPv6 address off the fde6:94f9:cb41:1/64 network:

Before:

em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet ....
inet6 fe80::beae:c5ff:fe22:8081 prefixlen 64 scopeid 0x20<link>
 inet6 ... my routed IPv6 network
 ether bc:ae:c5:22:80:81 txqueuelen 1000 (Ethernet)
 RX packets 5124271 bytes 2902863775 (2.7 GiB)
 RX errors 0 dropped 0 overruns 0 frame 0
 TX packets 3810992 bytes 608365311 (580.1 MiB)
 TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

After:

em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet ...
inet6 fe80::beae:c5ff:fe22:8081 prefixlen 64 scopeid 0x20<link>
inet6 fde6:94f9:cb41:1:beae:c5ff:fe22:8081 prefixlen 64 scopeid 0x0<global>
inet6 fde6:94f9:cb41:1:2059:a433:e3c7:78f3 prefixlen 64 scopeid 0x0<global>
inet6 ... my routed IPv6 network 
ether bc:ae:c5:22:80:81 txqueuelen 1000 (Ethernet)
RX packets 5124309 bytes 2902868846 (2.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3811007 bytes 608368684 (580.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Ok, so this is strange. And where does it come from? Someone trying to take over my IPv6 routing?

I decided to set a trap for the culprit:

First I logged the interface configuration for a box in my network. As soon as that IP shows up, I should have a time stamp on where to look.

And it turns out that between Thu Jan 30 09:47:54 PST 2014 and Thu Jan 30 09:47:59 PST 2014, something caused that interface address to appear.

In IPv6, a new address gets autoconfigured if a router advertises itself. Luckily I also ran radvdump to capture all router advertisements:

interface em1 {
  AdvSendAdvert on;
  AdvManagedFlag off;
  AdvOtherConfigFlag off;
  AdvReachableTime 0;
  AdvRetransTimer 0;
  AdvCurHopLimit 0;
  AdvDefaultLifetime 0;
  AdvHomeAgentFlag off;
  AdvDefaultPreference medium;

  prefix fde6:94f9:cb41:1::/64 {
    AdvValidLifetime 7200;
    AdvPreferredLifetime 7200;
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr off;
  };
};

There it is. Announced by the local fe80::1ab4:30ff:fe27:1f07 IP. Now what is that? It turns out, that is a device that generally is not pingable in my network. So do I have some spy device? Is there something hacking into my network?

There are a number of these route announcements in my tcpdump log:

09:47:58.244342 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
09:48:14.156450 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
08:47:57.266432 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
08:48:15.195973 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
07:48:03.139275 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
07:48:19.111124 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
07:48:31.750104 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
06:47:57.201278 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
06:48:11.111697 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48
06:48:28.080319 IP6 fe80::1ab4:30ff:fe27:1f07 > ff02::1: ICMP6, router advertisement, length 48

Generally speaking, these are 23 hours apart. Interesting…

Looking at my dhcp server log, these match up with IPv4 DHCP Requests:

Jan 30 09:47:57 x dhcpd: DHCPDISCOVER from 18:b4:30:27:1f:07 via eth0
Jan 30 09:47:58 x dhcpd: DHCPOFFER on 192.168.x.238 to 18:b4:30:27:1f:07 via eth0
Jan 30 09:47:58 x dhcpd: DHCPREQUEST for 192.168.x.238 (192.168.x.y) from 18:b4:30:27:1f:07 via eth0
Jan 30 09:47:58 x dhcpd: DHCPACK on 192.168.x.238 to 18:b4:30:27:1f:07 via eth0
Jan 31 08:47:56 x dhcpd: DHCPDISCOVER from 18:b4:30:27:1f:07 via eth0
Jan 31 08:47:57 x dhcpd: DHCPOFFER on 192.168.x.238 to 18:b4:30:27:1f:07 via eth0
Jan 31 08:47:57 x dhcpd: DHCPREQUEST for 192.168.x.238 (192.168.x.y) from 18:b4:30:27:1f:07 via eth0
Jan 31 08:47:57 x dhcpd: DHCPACK on 192.168.x.238 to 18:b4:30:27:1f:07 via eth0

Ah, a MAC address. Now it gets easy.

MAC Address Lookup returns “NestLabs”.

I am at the intersection of two things that are not that common:

  • I care a lot about IPv6 because I started to go IPv6 only in my home network and to as many sites as possible.
  • And I own a number of Nest devices. A Nest Thermostat and two Nest Protect.

I have the battery powered version of the Nest Protect. The one that checks in only once a day. Bingo!

So it turns out that a battery Nest Protect announces a strange IPv6 network when it turns on.

What? Why on earth would they do that? That is the question.

Hey Nest, care to comment?


Mar 28

On equals() and compareTo()

Most Java programmers know that there are four different ways to compare Java objects (==, equals(), the Comparable and the Comparator interface).

There is the reasonable assumption that when a.equals(b) is true, a.compareTo(b) is 0. 

But what about the other way around? A trap that we fell into at Ness was that we took JodaTime DateTime objects, shoved them into a SortedSet and out came a list of sorted dates. But when looking for a specific date in a list created from the same objects, it was not found.

The trap is, that two DateTime objects representing the same instant in time return 0 when compared, but when tested for equality using equals() they return false. In our case, one object used the local time zone and the other uses UTC.

DateTime shares that peculiar property with a small number of other classes, for example BigDecimal from the JDK itself.

Tested using groovy:

groovy.grape.Grape.grab([group:'joda-time', module:'joda-time', version:'2.0'])
import org.joda.time.*
a = new DateTime().withZone(DateTimeZone.UTC)
b= new DateTime().withZone(DateTimeZone.forID("America/Los_Angeles"))

println a.equals(b)
println a.compareTo(b)

produces

false
0

Jan 29

Does your IDE choice influence the way you organize your code base?

While working on open-sourcing a couple of components I was musing about the fact that I am doing similar work as some friends over at another company. However, there is one big difference: While I firmly believe that building a couple of small, independently developed and released components that can move at different development speeds and at different degrees of stability is a good thing, they have one giant source tree for everything.

They do release it in many separate pieces but the actual code base is one source tree. And everything gets released together with the same version.

When I joined my current company a little over a year ago, we were in a similar situation. And we made the conscious decision to split our code base up. Making it possible to take little pieces, isolate them, create a charter around them and then be able to say “this functionality or this piece of code belongs there”. Or, what is way more important, to be able to say “no, this should not go here”. Therefore giving the developers that are less familiar with the code base guidelines on how the can organize their code.

Looking around on the Internet and chatting with friends, there are many reasons why you want to do that. People call it “the google method” or want to keep “the code base squeaky clean because you have to compile all the code all the time” and others feel that it is necessary to be able to “re-factor every piece all the time”, which in component land, obviously would break any notion of backwards compatibility of APIs between pieces. 

While both ways of organizing source code have valid reasons, my personal experience (which is admittedly Java/JVM language skewed) shows an interesting and a bit disturbing pattern:

See, there is the one true IDE. And the one true IDE only allows you to open only one project at a time. If you want to switch to another project, you either must close your current project or must open multiple windows (one per project). This is inconvenient, and you need to context switch and yadda yadda yadda. When using the one true IDE, having one big source tree is the natural way to organize your code because that is how it was ultimately designed to work..

Compare that to the other true IDE. It can open an almost arbitrary number of projects at the same time in the same window. And when using maven, projects that reference each other, automatically get tied together. There is also an often overlooked feature called “Working Sets” which groups the projects that you are working on into a small and easily navigable sets. 

At my current day job, most people use the other true IDE. And the choice of using separate, small code bases worked very well for us. The only people that have so far given significant resistance or tried to overthrow this decision, were the ones that use the one true IDE. Obviously, none of them have ever raised the argument “Well, it is MORE CONVENIENT WITH MY TOOL CHAIN”, but if you read just a little between the lines, it is clear that this is an important reason for them.

As a software architect, tools are important but the more important question is: “What is the best choice for the organization?” And should a personal preference for a tool chain not only influence but drive the way an organization builds its code base? 

Is it better to have a few really large source code trees or is a larger number of smaller repositories the more sustainable way in the long run? 

For Ness, we made the choice of going with the larger number of small pieces. It has turned out to be a good decision and we can move fast because of this. And we made the decision after carefully thinking about the pros and cons of both approaches and revisiting it even a few times since then. We rationalized that decision away from personal preferences but because as a team, we decided that this is the best approach for long term sustainability of our code base. We did not allow a tool preference to drive this decision. 

If you find yourself in the situation where have to make a similar call, ask yourself whether you drive it or your tool chain. And what would the call look like if you took your personal preferences out of the equation. 


Feb 15

Source code formatting

Many people seem to have a strong stance on how their source code should be formatted. While for the odd one-person project, this is never an issue, as soon as there are two people collaborating, discussions about “how the source should be formatted” are inevitable.

Solutions are manifold: Some organizations come up with large and complicated style guides, that are guarded by style checkers and draconian consequences are threatened for people not fully complying to the style guide. Some cite studies from renowned academic institutions and industry leaders that turning everyone’s individual style into an uniform sauce makes it easier for everyone to work on anything.

Having written my share of style guides in the past (and tried to get others to adhere to it), here is my take on that:

It is all crap. Utter BS.

9 out of 10 times, having a style guide means that someone in the organization has a personal preference for formatting the source code “that way” and decided to use their power to get everyone else to comply. Been there, done that, got the T-Shirt (and the obvious amount of loathing from co-workers).

So in the end, I sat down and thought long and hard about this. What is it that I really want people to do. And why? So I de-cluttered and in the end, I came up with these rules. And what is more important, there are good reasons why you want to apply them. Everything else: Well, if your developers feel that code formatting is important to them, maybe it is time to ask why.

With no further ado, here are the rules. They are very Java centric, but can be easily adjusted to other languages.

  • "Always use spaces. Never use tabs."

Rationale: If tabs are used anywhere in the code, there will be places where the formatting is off. It might be the code review tool. Or the bug tracker. Or one editor displays the indenting different than another. It is not possible to get lots of different tools to treat tabs uniformly. A space is a space. Two spaces are two spaces. Seven spaces are seven spaces. No ambiguity.

  • "Always use curly braces, even if you could omit them. Never use ‘dangling statements’ for if, for, while and friends."

Rationale: Dangling statements are just asking for trouble. Combined with the first rule, if your indent is wrong, reading the code will give a wrong impression of the control flow. Adding another statement to a dangling statement is error-prone. Being uniform with curly braces means that there are less gotchas.

  • "Even if your source code formatting says "UTF-8", never use non-US-ASCII characters in the actual source code. Always use \u<xxxx> escaping."

Rationale: Using UTF-8 characters in the source code (not in the comments) leads to hard-to-find problems especially with cross-platform team (MacOSX is the worst offender here) development. Using \u removes all ambiguity.

  • "Never re-format other peoples’ source code."

Rationale: Reformatting leads to ugly diffs in your source code management system. Even if it itches your fingers, keep them off the “format in my style” key combination. This is the only rule that should be applied with a grain of salt, some things (e.g. DOS line endings) make sense to reformat. But moving braces around or changing indenting, just so that he piece of code you work on looks like your code? No. If you are a professional, source code formatting should be a non-issue to you and if the code you work on has the opening brace on a new line and a space before the semicolon and all you need to do is fix a single line, then for god’s sake, format that one line the same way as all the code around it.

And that is it. These are the only rules that I really really really like to see in source code formatting. Everything else is optional. IMHO.


Jan 18

A new blog

Sad but true. Ever since J. Random guy hacked the photo gallery connected to my old blog and I had to shut it down, I wasn’t really motivated to keep up-to-date with Wordpress security holes, bugs and the usual chores of maintaining a hosted server.

Enter tumblr. So there.

P.S.: First post. ;-)