Oh SNAP! There is more to Wi-Fi ↔︎ Ethernet than I thought

▼ The tag line for World IPv6 Launch ten years ago was "the future is forever". You know what else seems to be forever? The past. Let's talk about IEEE 802 LLC/SNAP encapsulation.

I always thought when you send IP packets over Wi-Fi, the IP packet would go inside an Ethernet frame, and then the Ethernet frame inside an 802.11 frame. Turns out this is not how it works: there is no Ethernet header inside IEEE 802.11 packets/frames¹.

What actually happens is that packets are bridged between Ethernet and Wi-Fi. Surprising. But the real shock is that the bridging between Ethernet and Wi-Fi is exactly the same as bridging between Ethernet and FDDI. (An old 100 Mbps fiber ring technology from when Ethernet was still stuck at 10 Mbps.) It's all laid out in this ancient RFC from 1988: RFC 1042.

Bridging is the process of translating one OSI layer 2 frame format to another. In this case, a Wi-Fi access point translates between the Wi-Fi 802.11 header and the Ethernet II header.

Most of the stuff in a Wi-Fi header or Ethernet header is only relevant on the Wi-Fi and Ethernet drivers, respectively. But higher layers in the networking stack do need to interact with two things from the Ethernet header: the MAC addresses and the ethertype. So bridging between two network protocols is possible if the MAC addresses and ethertype are compatible.

Which creates a bit of a problem, as the 802.x family, including 802.11, doesn't do ethertypes. So how do they make sure different packets, such as IP, ARP, IPX, AppleTalk, Wake-on-LAN, et cetera are interpreted correctly by the receiver? Their first try was the LLC header. But that didn't accommodate a sufficiently large number of possible protocols. So add to LLC the SNAP header. The ethertype goes inside the SNAP header. So now we have all the information we need to translate between 802.x protocols (such as 802.11 Wi-Fi) and Ethernet II. The slide below that I copied from this presentation shows how that works:

(Where DEST and SRC are the MAC addresses, type is the ethertype, and AA AA 03 00.00.00 are the values in the LLC and SNAP headers preceding the ethertype. P is the IP packet. Also see the last image here for an actual packet dump.)

But wait... isn't Ethernet IEEE 802.3, so shouldn't it use LLC/SNAP, too?

Well, kinda-sorta-but-not-really. Remember that Ethernet was developed by the DIX consortium (DEC, Intel, Xerox) and then handed off to the IEEE for further tinkering and standardization. As a result, there is a difference between the old Ethernet II header, which has the ethertype, and the 802.3 header, where the same place in the header is actually a length field. (Which we don't need, the Ethernet hardware can tell how long packets are just fine by itself.)

So for IP over actual IEEE 802.3 you need at least the LLC header (which supports IPv4 and ARP) but in practice IP over 802.x always uses LLC+SNAP.

So IP over Ethernet II is actually a relic from the past. But still quite alive. Novell did move to LLC and SNAP, but this just meant that there were now four different frame formats to choose from in your IPX network, and having four incompatible ways to do the exact same thing is never helpful when running a network.

¹ Remember, OSI layer 2 has frames, OSI layer 3 packets and OSI layer 4 segments. So the TCP segment goes inside an IP packet and the IP packet inside an Ethernet frame, each layer adding a header and sometimes a trailer with information relevant to that layer.

Permalink - posted 2022-07-21

My web tool for controlling (the color temperature of) Philips Hue lights

▼ Last year I got a new webcam, which led me to ask myself what color temperature setting for my Hue lightbulbs would work best with that camera. (Turns out: 4000K.)

But: how do you set your Hue lights to a certain color temperature? I didn't find a good solution for that. So I built my own! And then feature creep kicked in and I ended up with a browser-based tool that can control the lights in various ways. Including having the bulbs change their brightness / color temperature gradually over the course of seconds or minutes or even an hour.

So it got a bit more complex than ideal, and you need to jump through a few hoops to get the name or IP address of the Hue bridge and an authentication key. But I promise it's really nice. It has sliders for easy operation on an iPad and the like, but you can also use the keyboard.

Check it out.

Note that the whole thing runs inside the browser and directly talks to the Hue bridge over the local network. So no information is sent to the server. The authentication key can be stored in the browser's password store where it should be safe from prying eyes. But be careful with what you enter in the bridge IP address field because the authentication key is sent to the system with that address or name.

The huge bridge used to create the name "philips-hue.local" for itself, but now they they create a .local name from their MAC address. For instance:

ndp -a 00178827894e.local 0:17:88:27:89:4e en0 23h59m47s S

Permalink - posted 2022-07-12